I have no strong opinion about this.

> 2) EAPI in file extension
>   - Allows changing global scope and the internal format of the ebuild
>   a) .ebuild-<eapi>
>     - ignored by current Portage

simple, straightforward but ugly

>   b) .<eapi>.ebuild
>     - current Portage does not work with this

this only has disadvantages in front of a)

>   c) .<eapi>.<new extension>
>     - ignored by current Portage

same as a) but maybe less ugly

> 3) EAPI in locked down place in the ebuild
>   - Allows changing global scope
>   - EAPI can't be changed in an existing ebuild so the PM can trust
>     the value in the cache

This doesn't need a locked down place, just some strict way of setting
it, like at most one EAPI="constant_string_without_space" so that grep
& friends can catch it.

>   - Does not allow changing versioning rules unless version becomes a
>     normal metadata variable

I'm not entirely sure about this and would need some real
example/argument in order to be convinced

>     * Needs more accesses to cache as now you don't have to load older
>       versions if the latest is not masked

true but this "more" would need to be measured and opposed to the
number of metadata loads in a dep resolution procedure.

>   a) <new extension>

doesn't have the one year wait drawback and doesn't mess with pm
implementation details (eapi) with package names that shall represent
upstream ones.

>   b) new subdirectory like ebuilds/
>   - we could drop extension all together so don't have to argue about
>     it any more
>   - more directory reads to get the list of ebuilds in a repository

I see no advantage there vs 3.a)

>   c) .ebuild in current directory
>   - needs one year wait

That could have been done one year ago and would be done now; I think
it's still fine now because I don't expect major behavior changes in
the ebuild format within one year.

To summarize, I would retain 3.a as best solution, having the "usable
right now" advantage of current glep55 and keeping the ebuild's file
names (more or less) consistent with upstream ones.

Alexis.