I have an idea for a future EAPI after EAPI 9. That is allowing the EAPI to be determined by the package manager based on what features are used, so that way, using a metadata cache that is already in the current EAPI, we could use that to house the minimum required EAPI that is fully able to parse an ebuild using this feature. This would allow a ton of flexibility in writing ebuilds. Mess-ups like the ebuild to update the Zen Kernel I tried to upload could also be avoided.
I don't believe that this would be possible in a well-defined way. New EAPIs can come with changes in function behaviour (e.g. econf and insopts in EAPI 8) or with different defaults for phase functions (e.g. default_src_install has changed several times). Neither of these are detectable by the package manager looking at the ebuild. Also, there is no guarantee that an ebuild in a future EAPI would even be parseable by an old package manager. Sourcing it may error out because of a different Bash version (or we may even decide to switch to something other than Bash).
Not only what ulm said, but this would also add a heavy burden onto implementations and mean a reliance on heuristics that would move us away from formal, well-defined semantics/behaviour.
I think we'd be better off with hearing what issue you had with your ebuild: >Mess-ups like the ebuild to update the Zen Kernel I tried to upload could also be avoided.
