Currently within the resource merger it is not possible to
- use the jcr:primaryType of the underlying resource, while the overlaid/overridden resource has a different jcr:primaryType.
That is a problem because for a JCR the primaryType is mandatory for each node. Some node type definitions don't allow arbitrary property names like sling:hideResource. To be able to use those properties (which are only relevant up the point where the resource has been merged) you might need to use a more relaxed node type. Still you don't want that relaxed node type to appear as primaryType in the merged resource.
- use the sling:resourceSuperType from the underlying resource, while the overridden resource has a different sling:resourceSuperType.
This is kind of a edge case because sling:resourceSuperType would be used for two different things here:
- for getting the underlying resource path for the OverridingResourcePicker
- for the request resolution of the merged resource
Sometime the value for each of the cases would be different.
Therefore I propose a general property name mangling mechanism which allows someone to use a prefix like sling-resource-merging_ for the properties, which are during the resource merging exposed as properties without the prefix. One example for case 1):
In this example it is impossible to let my merged resource have the nodeType myCustomNodeRestrictedNodeType (because that simply does not allow the property sling:hideProperties to be set in /apps/my/resource.