Like you, I'm a bit confused about just what perlancar is doing (of course, no example code is given). In Perl as in life, there are a lot of ways to 'insert' things into other things, not all of which are appropriate in a given situation. I, also, don't understand why a regex cannot be defined as a simple string and/or qr-ed from the git-go.

... "It's not just the pattern, but the modifiers that must be compared".

But modifiers can be included within a string or qr regex definition (and IMHO, should only be used in this way in the case of the  /i modifier).

c:\@Work\Perl>perl -wMstrict -le
"print $];
 ;;
 my $rxs = '(?i) (?: a|b)';
 my $rx  = qr/$rxs/xms;
 print $rx;
"
5.008009
(?msx-i:(?i) (?: a|b))

c:\@Work\Perl\monks\>perl -wMstrict -le
"print $];
 ;;
 my $rxs = '(?i) (?: a|b)';
 my $rx  = qr/$rxs/xms;
 print $rx;
"
5.014004
(?^msx:(?i) (?: a|b))
[download]

But modifiers can be included within a string or qr regex definition (and IMHO, should only be used in this way in the case of the /i modifier).

Indeed they can, and that's actually what stringification of qred regexes does, I was thinking about context-dependant changes, like use re. You could still write the whole set of modifiers in the string to be sure to get what you want no matter what the context is though.

In my module (DateTime::Format::Alami), I'm building a big regex from potentially hundreds of smaller bits (which will be retrieved from a method and applied some preprocessing). This regex won't change between runs, so in order to save startup time, I'm precomputing it during dist build time. (I don't know how big the saving will be though, so perhaps this is premature optimization.)

There's another use-case where I put regex literal into the built source code with Dist::Zilla: inserting code-generated argument validation code. I do this in some cases where I want the autogenerated argument validation code to be embedded directly into the source code and not generated/called dynamically during runtime (and thus usually adds another subroutine call level or startup overhead time, because in my case the argument validation code generator has quite a bit of startup time). An example:

sub foo {
    my ($arg1, $arg2) = @_;
    # INSERT CODE VALIDATION HERE
    ...
}
[download]

During build, a Dist::Zilla plugin will fill in the code validation routine:

sub foo {
    my ($arg1, $arg2) = @_;
    defined($arg1) or die "arg1 is required"; $arg1 =~ qr/\A\w+\z/ or 
+die "arg1 must be alphanums only"; defined($arg2) or die "arg2 is req
+uired"; # INSERT CODE VALIDATION HERE
    ...
}
[download]

I hope that clears up things a bit.

And even if the above two use-cases are not commonly had with other programmers, I'm still curious about the problem of handling regex stringification backward-incompatibility in Perl 5.14.

doing something during build-time or at the beginning of run-time is equivalent time-wise

True, but the cost is moved to build-time and users are not bearing it :-) Suppose it takes you 0.50s to assemble a giant regex from smaller bits taken from a bunch of submodules. While the assembled regex literal only takes 0.01s for Perl to parse. Your module users will only take the 0.01s hit at startup time and not 0.50s.

if the stringification compiled regex doesn't suit your needs, why don't you dump the pattern before compilation

Yes, in this case I actually can, because I'm assembling the regex from strings. So before I turn it into a Regexp object, I can print the string first. My particular problem is solved. Thanks! :) But suppose I already have a regexp object? How do I stringify it under 5.14+ so it is compatible with 5.10 & 5.12?