It occurs to me it wouldn't be all that difficult to support the ability to define soft forks entirely as standalone units that can be trivially merged with Bitcoin Core. It would require a few changes in some places in the consensus code, but at least for a very wide class of potential soft forks, all cases could be covered via only a small number of hooks, primarily in main.cpp, consensus/*, script/interpreter.cpp, and primitives/*. (Other hooks could be added in non-consensus code such as rpcblockchain.cpp or the wallet). It would be possible to build unit tests for each soft fork independently and compare enforcement of different combinations (as well as simulate these deployment combinations on regtest).

Before I get too heavily invested in this idea, though, I'd like to see if there are any reasonable objections to such a thing. Of course, refactors are generally disruptive in the short-term...but I think what I'm talking about can be done without having to move very large chunks of code around, with very specifically defined hooks that can be easily documented to make backports fairly simple.

My biggest concern (other than being able to convince everyone that we won't break anything, which of course I'd have to do a good job of in terms of rigor) is whether supporting this feature is a good idea in the first place. There's something to be said for it not being *too* easy to write and deploy a soft fork...however, unless we open this up a little more and make such deployments more routine (and safe) it will take a very long time to deploy stuff. A significant motivation behind VersionBits (BIP0009) is to make such deployments faster, so if we're already doing that perhaps we might as well take this initiative even further.

If others think this is a good idea I'll start writing up a detailed plan. (NOTE: The current versionbits deployment plan does not require this. I am working on an implementation of versionbits that could potentially support this plan but doesn't have to.)