The move to a flatter versioning system is welcome because it almost all cases we have no requirement to have versions on versions on a version. There's change required to production data in multi-user editing, and that's it, so just the one child version per change (which only lasts as long as the edit lifetime) is all we need. In fact unraveling accidental grandchild versions is the only thing we do with the current multiple layer versioning system.
The move to a service-oriented system is also welcome and a great innovation, allowing much greater flexibility, scope and wealth of applications working with enterprise data across the internet, especially important while staff and clients can both be working from home during COVID-19.
One thing that is a concern though is we currently allow users to create, edit, reconcile and post their versions to DEFAULT (we use customisations to prevent direct editing of DEFAULT) but this seems no longer possible unless we make them feature layer owners or portal administrators.
We'd like to retain the efficiency of self-managed editing with a minimum administration overhead with protected DEFAULT version. But it's inadvisable leave it unprotected or to make all users of the service Owners and unsafe to make them all Portal Adminstrators just to be able to reconcile and post to DEFAULT. We'd also like to remain as close to COTS as possible to deliver development and support efficiencies.
What would be ideal for our workflow is if in Enterprise permission can be given to allow classes of users the ability to create, reconcile and post their versions to a protected DEFAULT branch version, but not edit the default version directly.