Partial Configurations handled by the LCM is a terrible implimentation
Frequency: Always Happens
Regression: feature unavailable in previous versions.
The current implementation of Partial Configurations is ... to put it mildly ... awful. By placing the actual merge of the various MOFs on the agent you create more problems than you solve:
Adding new configurations, which can be of a consequence as simple as an existing configuration getting too large, now requires a complete reconfiguration of each node so the nodes are aware of the change.
There is no way to do any kind of collision detection or configuration validation before it reaches the host, as the pull server does not present a singular MOF (the final config is scattered).
It ultimately doesn't solve management of configuration files in as it merely creates multiple unique "pools" of data that never interact before the LCM.
In summary, the way it is implemented solves a problem that doesn't exist: allowing multiple teams to edit configurations which can be handled today at the source code ... there's no need to build multiple delivery systems which put responsibility on the agents.
How Partial Configurations should be handled
Allow a configuration to include other configurations. For example:
Include-Configuration IIS DC WSUS
Done. A simple include statement in a configuration would allow me to create a final configuration that reuses existing standards and still process a SINGLE configuration that results in a single mof (with all possible issues revealed during the compile) and no reconfiguration of the client needed.