Improve encapsulation of logic for handling ordered resource children

Currently, a resource that has ordered child resources needs to define this logic in 3 places:

1. The ResourceDefinition needs to indicate that it supports indexed adds (solely for adding the appropriate add-index description) by overwriting SimpleResourceDefinition.isOrderedChildResource()
2. The add operation handler of the parent resource needs to override AbstractAddStepHandler.getResourceCreator() to provide an implementation of OrderedResourceCreator that dictates which child types will be ordered
3. The add operation handler of the ordered child resource needs to override AbstractAddStepHandler.getResourceCreator() to provide an implementation of OrderedResourceCreator that indicates that the resource supports add-index.

IMO, this seems like poor encapsulation. If we added a ImmutableManagementResourceRegistration.isOrderedChildResource() method, then the AbstractAddStepHandler can query the resource registration to determine whether the current resource supports the add-index parameter, and to see which child types are ordered. This would eliminate the need for subsystems to do #2 and #3 - based solely on the information provided by #1.
Also, indicating this behavior (i.e. #1) via overriding a protected method also seems a little hacky/tacked-on. This method is only read by the SimpleResourceDefinition constructor - which means that this information is more appropriately provided by the constructor. I assume it was done this way since the SimpleResourceDefinition constructors are already overly polluted/complex. Why not instead define this behavior by:
ManagementResourceRegistration.registerOrderedSubModel(ResourceDefinition)
or
ManagementResourceRegistration.registerSubModel(ResourceDefinition).setOrdered(boolean)?
Thoughts?