Edition based redefinition (EBR) is a great feature. However there are also some drawbacks.
One drawback is that is is very difficult to have multiple applications in the same database that each use there own editioning concept without getting into conflict with each other.
I suggest to implement editions as a schema level concept.
An edition is for the whole database (whole PDB). Splitting the applications accross different PDBs would avoid this, but is not a proper solution. First there are licensing differences, but more importantly the desicion what is a schema and what is a database should not be based upon EBR feature usage but on sound achitectural differences. Maybe the different schemas are managed by different teams of developers all building the same application (just different building blocks).
The suggestion is that each schema can have its own editions. Those editions would be independend from editions inside other schemas.
What do we gain?
Each schema can deploy a new application version (=a new edition) without overwriting the editioned objects form another schema.
An example
We have an apex application based upon the HR schema. We now want to deploy a new version. So we create a new HR.edition2. Deploy our plsql packages and views there.
At the same time the APEX team publishes a new APEX version. Using EBR they provide a way to do the upgrade using a zero downtime approach. They install a new edition deploy the new code there.
Currently running apex sessions still run in the old version. New sessions would be switched to the new session.
At the moment this would not work, because we only have edition per database container. For example what happens if we decide to go back to our old HR version. Meaning we want to drop the HR edition2. However this would require to drop the new apex edition too.
There are serveral similar conflicts. All resulting in because different responsibilites exists alongside in the same database. And editions need to be matched to this level of responsibility.