(d) and (e) would populate the unprocessed domain.xml fragements to a MetaDataRepository in a domain scope. This is needed since we have to distribute this to the whole domain - so we cannot do system property replacement there, as system properties in some cases could be just for a single instance/node e.g. ports-01.
Additionally we also need to populate the MetaDataRepository with default values, those have to be kept separate until the point we actually do transformations/injections of the domain metadata itself. Basically to reduce the size of the domain.xml to configuration overrides - additionally we can compare and only store changed values back to the domain.xml
IMO something other than the MDR should be created/used to achieve this. The MDR's design is in many ways incompatible with what we actually want for a domain model. As an example, the notion of scoping is the exact opposite of how an administrator expects the domain.xml to work. An entry in the domain should *override* something expressed in a deployment, not the other way around.