> I think this is adding excessive complexity.

It really depends on how many incompatible features there are, and how difficult it is to turn them on/off.

> I think it is reasonable to pick a *set* of features as a whole

It's probably more practical, but otherwise I'm not sure why you would want to activate 2-5 unrelated features that might require you to rewrite your regex (assuming you are aware of what the features are, what are their side effects, how to fix your regex) just because you need one.

The idea is to make the transition smoother and not having a pre-regex world and an incompatible post-regex world, divided by a single flag.

> If you don't want a feature, don't use it.

With only one flag you are forced to enable all the new features, including the ones you don't want.

> "Feature flags" leads to a combinational explosion that makes
> comprehensive testing all but impossible.

We already have several flags and the tests are working fine.  If the features are orthogonal they can be tested independently.

> The alternative is hard to track down bugs:
> "this regular expression returns the wrong result, but only if you
> have flags A, B and G turned on and C and F turned off."

What about: "X works, Y works, and X|Y works, but when I use NEW flag to enable an inline flag X|Y stops to work while X and Y keep working" (hint: the NEW also enabled nested set -- see msg143333).

I'm not saying that having multiple flag is the best solution (or even a viable one), but it should be considered depending on how many incompatible features there are and what they are.