EXTENDED_PATTERNS option?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

I have made no coding progress at all on the suggestion I'm about to make,
but for purposes of discussion:

Might it be sensible to separate the EXTENDED_GLOB features into two
contexts?  Namely, filename generation and pattern matching, so that for
example one could have backreferences enabled in [[ ... ]] expressions
while at the same time NOT have "^" and "#" take on special meaning in
globbing.

Thus the suggestion that EXTENDED_PATTERNS enables (#s), (#e), (#m), etc.
in conditional expressions, whereas EXTENDED_GLOB behaves as it now does
(implying EXTENDED_PATTERNS).

[An alternative worth careful consideration is to have EXTENDED_PATTERNS
active by default, and use EXTENDED_GLOB only during filename generation.
There is a small chance that some conditionals in existing code would
change behavior if this were done.]

One complication to this of course is that (#q) now turns on globbing
inside conditionals, and the (e::) glob flag evaluates conditionals, so
flipping global state of the pattern code on entry/exit of either context
is fraught with potential confusion -- perhaps so much so as to scuttle
the idea.

Any thoughts?

Aside:  Rope to hang yourself:  [[ -f  *(#qe:unsetopt extendedglob:) ]]

Aside part 2:  Why doesn't (#q) work to cause globbing in [[ x = y ]] ?
The doc says "it can be forced in any case where normal shell expansion
is valid" but what does that mean inside a conditional?