I'm launching my first project that uses Features heavily, and I've run into some of the limitations discussed in this post by Bill at Funny Monkey.

Bill talks about the difficulties in deploying multiple sites from a set of Features, and then keeping those sites in sync with the Feature as it evolves, and how that process is incompatible with Drupal's goal of making it possible for non-technical content admins to do more things.

A similar set of problems arise when you are using Features to keep dev/stage/live instances of the same site in sync.

We're using drush to sync code from dev->stage->live and to sync content from stage->live and stage->dev (the Pantheon model).

There are some variables that you'd like to be set differently on dev, stage, and live (e.g. performance/cache settings). We solved this by creating different Features/Strongarm modules for each instance.

There's an additional Feature that tracks shared variables.

If a content admin changes a variable that's covered by the shared feature module, they probably want the change to propagate to the live server.

If they change a variable that's covered by the instance-specific feature module, they probably don't want it to propagate.

Unfortunately, we can't cover both use cases at the same time. If the variable table is part of the content push, then configuration changes will be pushed and strongarm will be overridden. If the variable table is excluded, then configuration changes will not be pushed.

Furthermore, there's no way for the admin to know that a particular setting is Strongarmed, so it's easy for a content admin to unwittingly break things.

I'd like to see some new features in Strongarm to help handle things a little better. These might be applicable ot other Features as well.

1. Some kind of UI change on settings forms to show which variables are strongarmed.

2. Locked variables. It should be possible to "lock" a variable with Strongarm so that it can't be changed through the UI. Frustrating for the content admin, but at least it will reduce surprises. Maybe this could be a suggestion (a second click is required to unlock the setting before changing it?).

3. Local overrides. When a setting is strongarmed, it is removed from the variable table. If the setting is later overriden, it returns to the variable table. If the Strongarm Feature is reverted, the setting is again removed from the variable table.

If there was a way to override a strongarmed setting without affecting the variable table (perhaps via a separate strongarm_variable table?) it would be possible to stage the variable table without staging overridden settings (you'd exclude the strongarm_variable table instead).

If it was possible to restrict a setting to being overridden locally, all possible content staging use cases could be fulfilled.