'existing' assignment plugin runs too early

It should be possible to rerun feature assignment at any time within a given bundle and have the resulting features reflect the (potentially, altered) assignment configuration.

This is the key question here. As originally designed, assignment plugins are not for one-time use (only when creating a feature for the first time). Rather, it should be possible at any time to tweak them and rerun them, which should result in items being reassigned from one feature to another.

For this to work, though, we can't immediately redo all existing assignments. As things stand, tweaking the settings after the initial features export will have little or no effect.

If configuration has already been exported to a Feature module, then you don't want assignment plugins to change that by default. Otherwise you could easily end up messing up existing Features unintentionally.

I think you do want assignment plugins to change that by default, but you also want a way to ensure that specific items are not reassigned. Hence the need for #2446805: Add "required" components for a given feature.

I'm seeing it like this:

• I generate a feature.
• Whenever I manually add or remove an item it's marked as required or excluded.
• When I regenerate a feature, the required/excluded plugin runs early (where the existing one now runs) and ensures that any previous explicit assignments are retained. Then the existing plugin runs late, to ensure that any leftover assignments are remade.

So the fix looks to me like:

• Mark this issue as postponed, since it depends on #2446805.
• Complete #2446805.
• After that, this can be reopened.

More generally:

I'd like the power of assignment plugins to be a more advanced feature that people don't need to worry about if they just want to use Features the way they did before.

While I see the attraction of familiarity, I think we should aim to significantly improve features approaches in D8. D7 features in general are a mess. They are so arbitrarily structured as to make interoperability a statistical impossibility. By baking in sound design principles, we can provide the basis for better practices. And for this to work, we need to the ability to reassign after initial features generation.

Since I didn't "manually add" these items, they wouldn't have gotten marked as "required"

Yeah, I think we need a way to explicitly mark a config item as required. I guess there are three states: required, excluded, and default.

This would be similar to the locking as available in D7, except that the state is saved with the feature export, not as a local variable on each install.

a site builder using Atrium could still inadvertently move stuff out of the distro's features breaking their site

This shouldn't be a risk because the reassignment should only happen within a given bundle. The exclude assignment plugin with its default settings should ensure that any configuration provided by modules outside of the current bundle isn't available for assignment.

Depends on #2446805: Add "required" components for a given feature.

#2446805: Add "required" components for a given feature is fixed but this now is blocked by #2596047: Duplicate packages generated.

#2596047: Duplicate packages generated is now fixed, which cleared the way for this change.