Raise deprecation for qr/(?foo})/

An unescaped left brace that is meant to be taken literally is
officially deprecated, though there are no plans to remove it in contexts
where we don't expect to use it to mean something else, and no warning
is raised in those contexts.

reg_mesg.t tests the known set of these contexts, currently (after this
commit):

 /^{/
 /foo|{/
 /foo|^{/
 /foo(:?{bar)/
 /\s*{/
 /a{3,4}{/

 This commit deprecates this context:

 /foo({bar})/

 This probably should have been illegal all along when 'bar' is a valid
 quantifier, as we do with the other quantifiers that follow a left
 paren whose illegality we haven't already taken advantage of to mean
 something else:

    qr/(+0)/
    Quantifier follows nothing in regex

This deprecation will allow ({...}) to be usable for a possible future
regex extension

1 files changed, 27 insertions, 23 deletions

diff --git a/pod/perldeprecation.pod b/pod/perldeprecation.pod
index 8cd3eb950f..a00ceac76f 100644
--- a/pod/perldeprecation.pod
+++ b/pod/perldeprecation.pod
@@ -84,6 +84,31 @@ something useful.  To avoid these bugs, the function is being made strict.
 Passing arguments was deprecated in Perl 5.28, and will become fatal in
 Perl 5.32.
 
+=head3 Unescaped left braces in regular expressions
+
+The simple rule to remember, if you want to match a literal C<{>
+character (U+007B C<LEFT CURLY BRACKET>) in a regular expression
+pattern, is to escape each literal instance of it in some way.
+Generally easiest is to precede it with a backslash, like C<\{>
+or enclose it in square brackets (C<[{]>).  If the pattern
+delimiters are also braces, any matching right brace (C<}>) should
+also be escaped to avoid confusing the parser, for example,
+
+ qr{abc\{def\}ghi}
+
+Forcing literal C<{> characters to be escaped will enable the Perl
+language to be extended in various ways in future releases.  To avoid
+needlessly breaking existing code, the restriction is is not enforced in
+contexts where there are unlikely to ever be extensions that could
+conflict with the use there of C<{> as a literal.
+
+Literal uses of C<{> were deprecated in Perl 5.20, and some uses of it
+started to give deprecation warnings since. These cases were made fatal
+in Perl 5.26. Due to an oversight, not all cases of a use of a literal
+C<{> got a deprecation warning.  Some cases started warning in Perl 5.26,
+and they will be fatal by Perl 5.30.  Other case started in Perl 5.28,
+and will be made fatal in 5.32.
+
 =head2 Perl 5.30
 
 =head3 C<< $* >> is no longer supported
@@ -132,30 +157,9 @@ disappear in Perl 5.30.
 Code using C<< File::Glob::glob() >> should call
 C<< File::Glob::bsd_glob() >> instead.
 
+=head3 Unescaped left braces in regular expressions (for 5.30)
 
-=head3 Unescaped left braces in regular expressions
-
-The simple rule to remember, if you want to match a literal C<{>
-character (U+007B C<LEFT CURLY BRACKET>) in a regular expression
-pattern, is to escape each literal instance of it in some way.
-Generally easiest is to precede it with a backslash, like C<\{>
-or enclose it in square brackets (C<[{]>).  If the pattern
-delimiters are also braces, any matching right brace (C<}>) should
-also be escaped to avoid confusing the parser, for example,
-
- qr{abc\{def\}ghi}
-
-Forcing literal C<{> characters to be escaped will enable the Perl
-language to be extended in various ways in future releases.  To avoid
-needlessly breaking existing code, the restriction is is not enforced in
-contexts where there are unlikely to ever be extensions that could
-conflict with the use there of C<{> as a literal.
-
-Literal uses of C<{> were deprecated in Perl 5.20, and some uses of it
-started to give deprecation warnings since. These cases were made fatal
-in Perl 5.26. Due to an oversight, not all cases of a use of a literal
-C<{> got a deprecation warning. These cases started warning in Perl 5.26,
-and they will be fatal by Perl 5.30.
+See L</Unescaped left braces in regular expressions> above.
 
 =head3 Unqualified C<dump()>