[Meta] (8.x - Features on CMI) Goals, Design, and Architecture

I see a couple ways forward. Option A describes a status quo approach to the design, Option B struggles toward a new fundamental concept for how Features works.

Note: As a reminder, I am not a Features maintainer. This is a couple proposals I am lobbing in to get the discussion started.

Option A (Status Quo)

CMI has already introduced mechanisms to export configuration for a site en masse. An 8.x-2.x version of Features might pull the UI forward for the most part, and replace the guts with something as follows:

• Features Pipe Logic (the thing that takes the .info file records for features, runs some alter hooks, and identifies component "ownership") might be replaced by Features config entities.
• Extend the export mechanism to whitelist elements by the Features pipe logic
• Create a new under-the-hood element of the Features UI that takes the whitelisted subset of site configuration and sets it as the default installation configuration of a new or existing module.

The upshot of these points is a refactored Features module that retains all the known patterns of Features Export, Features Update, and possibly Features Revert for development purposes. Downsides are preserving these concepts, which are well-understood but an outgrowth of Drupal's former limitations.

Option B (Revolution)

This approach is still a bit hazy on account of my still incomplete understanding of the configuration system. The point here is not to sit Features on top of it, but to work with it from the inside to make it a better facilitator for the kinds of things Features does. I think of this as the 8.x-3.x approach to Features, but I suspect I'm describing multiple modules or even projects.

The layers I'm thinking of are as follows:

• Configuration Storage Splitter: Whenever you save a form, it stores the change to the configuration cache and to the permanent record that is the configuration files. Extending this concept further, make it possible for any configuration storage engine to be used simultaneously, and provide some tools to manage comparison.
• Configuration Change Subscription: Modules may "subscribe" to the changes associated with configuration namespaces. As such changes happen, their own configuration defaults are updated to match. This only happens in a site set to some sort of developer mode.
• Features "Use Case" UI: A UI that allows the definition and management of module subscriptions, focusing on helping pull together related configuration components (fields with a bundle, etc).

The general effect of this concept is to configure modules that automatically pick up on configuration changes made throughout the site. The goal here is to keep the purpose of Features intact, but streamline the development process by using Configuration Management internals instead of creating ever-more-convoluted ways to run an export.