The only qr// flag that could sanely be overridden is /i and in this case I still call the current behaviour a bug.

Nope. I disagree. If thats a bug then there would be no way to disable /i from inside the regex when the i modifier is used. Which would totally break quite a few regexes that I have. And conversly, would putting a regex compiled with /i into a regex without /i cause the i to cease functioning? Definately not a bug.

I'm taking a positivist approach to this. Where /i is specified it overrides, where it is not, it doesn't. So /$re/i has a local definition of /i but /$re/ doesn't. This implies that where a local redefinition occurs you've gained nothing in performance because the regex fragment must be recompiled to match the local expectations. I think that's just too bad. The alternative viewpoints here might be that the potential performance hit is unacceptable (even given the logical disconnect) or that a a regex fragment is actually a universe unto itself and just because it is included in a larger regex the larger regex's rules shouldn't apply.

I'm still holding out for a positivist interpretation of this.

I think you are missing the idea behind this,

 
$regex = qr/test/;
[download]

this compiles to (?-xism:test) meaning you are stating that the string test must exist and be lowercase. so ...

if (/$regex OtherWord/i) {...}
[download]

This seems very logical to me that this should match "test OTHERWORD" but not "TeSt OtherWord" as I have defined $regex to be case sensitive explicitly ! Are you really stating that you feel you need to

if (/(?-ixsm:$regex) OtherWord/i) { ... }
[download]

to accomplish this case insensitivty on the qr var?? That just blows me away.

-Waswas

You wouldn't.