Judging from the current state of SchemaAwareApplyOperation and its subclasses, it seems the various specializations have resulted in quite a bit of pasta.

This is a maintenance burden, as the various overrides and especially the AutomaticLifecycleMixin indirection causes quite a few turns to be taken to track down what exactly goes on when.

It also leads to a lot of method overrides which essentially perform either argument adaptation, or check the results of their super operation. This is notably true for min/max validation, AutomaticLifecycleMixin (and its users) and MandatoryLeafEnforcer. This leads to megamorphic execution profile, where the compiler has to deal with various method invocations in different call sites.

It seems the code structure should be amenable to splitting the various aspects of SchemaAwareApplyOperation into specialized interfaces (or abstract classes), and then composing individual implementations from these aspects.

Most notably we should strive for having each aspect implemented in two implementations: one for the 'common path' and one forwarding/decorating. This should make the code flows more straightforward, as it becomes clear what the actual interactions are and what special-cases we are performing.

Having two implementations will also mean method invocation will become bimorphic, which is something HotSpot can handle really well.