- Module A (say, Book) can ship with default config that actually pertains to Module B (Node).
- The current system assumes always-compatible config objects, which is known to be invalid.
- Correctly handle API compatibility for configuration in module interdependencies.
- Allow modules to reject incompatible configuration during installation/import.
- There happens to be an "export API version" as the base integration part of CTools' Export API, Views API, Panels API, etc.
- The new configuration system does not have any version identifiers or compatibility checks, albeit almost fully mimicking the basic export/import concepts of Features/CTools in D7 contrib.
- E.g., admin_views.module can provide default config (views) for views.module, but which are only compatible with views 3.x, and on top of that, they also require VBO 2.x. The views definition is only compatible with Views 3.x and incompatible with Views 2.x. The VBO plugin definition is only compatible with VBO 2.x and incompatible with VBO 1.x.
- Thus, either all modules are forced to work with any kind of version-agnostic config at any time — which is the current situation and effectively means "backwards-compatibility for eternity."
- Or we not only need to trust the module API, but we actually need to introduce an additional mechanism/way to allow modules to "reject" config if it is not compatible during any kind of installation/import.