|Do you know where your variables are?|
My interpretation of the behaviour is that you're running afoul of ▀ (sz-ligature) matching SS when doing a case-insensitive match. This means that Perl will try to match s "inside" of ▀, which then results in a variable-length look-behind pattern.
This theory easily explains the first behaviour, as Perl compiles
This creates a variable-length lookbehind, which is what Perl does not like.
For your next examples, each "s" might start "inside" of an (expanded) ▀:
I don't know why your third example compiles when the others do not, but I blame this on the inconsistency of ▀ matching ss. My suggestion would be to try to avoid /i and instead enumerate the alternatives if possible. That would mean to expand at least the critical words starting with s to character classes matching the upper- and lower-case variant:
Maybe you can fudge things by constructing your master regular expression from even more parts:
I don't know why it doesn't happen for statically compiled regular expressions. Maybe this is the real bug here.
In reply to Re: qr/STRING/ fails with certain lookbehind expressions