In this constructor, I see the following logic:
1. Try to find the sling:resourceType property, set in any of the resources
2. If that property could not be found, try using the relative path
Then, even if a proper sling:resourceType property was found, it will overwrite that value with the result of Resource#getResourceType if it is not null, of the last resource that defines one. This could be entirely right (maybe this done because some people use wrappers, that override the getResourceType-method?).
However, in the JCR implementation of Resource (JcrNodeResource/JcrItemResource), it is rare for getResourceType to return null, because:
1. Try to return the defined sling:resourceType's value
2. If not found, try to return the value of jcr:primaryType
Generally, any node has a jcr:primaryType defined and thus returns it.
When the overridden resource does not mention a resource type, this effectively makes getResourceType of the merged resource return the node type of the overridden resource (in our case: nt:unstructured).
Easy case to reproduce:
/libs/test (@jcr:primaryType: nt:unstructured, @sling:resourceType=website/component, @prop=test)
/apps/test (@jcr:primaryType: nt:unstructured, @prop=test-overridden)
(Marked in the bold, the values I think are not correct in this case.)