The main things to note about this are:
a) This distinguishes between selecting a composite solid ['composite_a'] and selecting all of the composite's children ['composite_a.solid_a', 'composite_a.solid_b']. In the first case, config mapping is respected; in the second, it is not. Subselecting from a composite ['composite_a.solid_a'] does not respect config mapping.
b) This collapses composite subselections, so that, e.g., 'composite_a.composite_b.solid_c' takes config like {'solids': {'composite_a.composite_b.solid_c': {...}}}. So this does synthetic naming in the subselection.
In order to enable the alternate approach, where 'composite_a.composite_b.solid_c' takes config like {'solids': {'composite_a': {'solids': {'composite_b': {'solids': {'solid_c': {...}}}}}}}, we would either need to inject synthetic composite solids into the subpipeline (hard to understand how this would work when we no longer subclass PipelineDefinition), or we would need to specialize environment schema generation for the subpipeline (but see https://github.com/dagster-io/dagster/issues/2322 -- we may have to do this anyway).