Could you show some examples of those packages?

yeah, the abstract statement is a bit hard to visualize.  would help if you could provide concrete examples.

oh, sure.

One example is;

https://chromium.git.corp.google.com/chromiumos/overlays/chromiumos-overlay/+/75825748f1e9b3a9961a56e3c741fa84a1f563a3/media-libs/cros-camera-libcab/cros-camera-libcab-9999.ebuild#10

vs

https://chromium.git.corp.google.com/chromiumos/overlays/chromiumos-overlay/+/75825748f1e9b3a9961a56e3c741fa84a1f563a3/chromeos-base/chromeos-login/chromeos-login-9999.ebuild#7

Specifically, for platform2 location, first one is ../platform2/, while second one is platform2/.
According to the cros_workon.eclass:

# @ECLASS-VARIABLE: CROS_WORKON_LOCALNAME
# @DESCRIPTION:
# The relative path in the local manifest checkout to find the local git
# checkout.  The exact path it is relative to depends on the CATEGORY of the
# ebuild.  For chromeos-base packages, this is relative to src/.  For all other
# packages, it is relative to src/third_party/.  This applies to all ebuilds
# regardless of the overlay they live in.
# If looking at a manifest.xml, this is related to the "path" attribute of the
# "project" tag (although that path is relative to the root of the manifest).
: ${CROS_WORKON_LOCALNAME:=${PN}}

In reality, the checkout path logic is more complicated:

https://chromium.git.corp.google.com/chromiumos/overlays/chromiumos-overlay/+/75825748f1e9b3a9961a56e3c741fa84a1f563a3/eclass/cros-workon.eclass#271

it depends on package name, CROS_WORKON_SRCPATH, and also actually looks at the actual local file system.

Also,
https://chromium.git.corp.google.com/chromiumos/overlays/chromiumos-overlay/+/75825748f1e9b3a9961a56e3c741fa84a1f563a3/eclass/platform.eclass#92
makes the situation a bit more complicated. I hit this on arc-camera repository migration.
When platform/arc-camera is migrated into platform2/camera, the checkout repository is one, and I used to set OUTOFTREE build to 0,
because the original code was modifying the checkout file directly.
However, then, {S} points to somewhere weird directory, and build failed.

I think, it'd great if we could simplify and clean them up.

Thank you for the examples. Sounds like a good cleanup work item to me.

my preference (and i thought i'd filed a bug, but maybe i only talked with people) would be to get rid of the automatic third_party-vs-platform expansion and only ever root it at src/.  then every ebuild must explicitly list third_party/ or platform/ themselves.

i'm not aware of any cros-workon package that isn't under src/.  but maybe we could adapt the convention that if the var starts with a /, then we don't autoprefix it with src/.

so we should:
- delete CROS_WORKON_SRCPATH entirely.  we never set it to anything.
- make CROS_WORKON_SRCROOT read-only ... it's currently written as if people could override it, but we don't actually want that.
- change logic to (temporarily) not add any path prefixes if it starts with "platform/" or "third_party" or is set to "platform2"
- require every ebuild to set CROS_WORKON_LOCALNAME explicitly (no more defaulting to $PN) relative to src/
- drop all autoprefixing logic related to CROS_WORKON_LOCALNAME
- throw an error if CROS_WORKON_LOCALNAME starts with "../"

> i'm not aware of any cros-workon package that isn't under src/.  but maybe we could adapt the convention that if the var starts with a /, then we don't autoprefix it with src/.

I think it's safer to reflect the Chrome OS repository,
and don't handle "src" as special case.
So, if platform2 is needed for the build, let's check out it under
src/platform2/...

Actually, we hit the issue because platform2/ is handled in the special rule.
Let's keep the structure as simple as possible.