...
If the existing service resolution functions are better encapsulated behind an implementation of ServiceDeploymentReader provided by DOManager, DOManager becomes the logical place for the steering decision (based on the SDep's content model). One hitch is the resource index rebuild: A DOManager isn't necessarily available to the triple generators. Perhaps DOManager could share a delegate for driving this behavior with DirectoryRepositoryReader?
Module Architecture
Even in a scenario that preserves existing CMA 3.0 object markup, the proposed change to a model-dependent loading of deployment readers and triple generators obviously touches on the discussion of changes to the module architecture. If it was acceptable to include some additional libraries in a 3.4 release, it's possible that these changes could provide a laboratory setting for the module architecture changes to come (assuming that the overall change is a 4.0 feature).
4.x CMA Sketch
More to come, but presumably moves away from any WSDL specification as the default type.