Some reflow and clarifications

doc/Language/5to6-nutshell.pod6

@@ -1642,10 +1642,10 @@ say [ :$foo, :$bar, :@baz ].perl;
 # OUTPUT: «["foo" => 42, "bar" => 44, "baz" => [16, 32, 64, "Hike!"]]␤»
 =end code
 
-There is also a debugging aid for developers called C<dd> (Tiny Data Dumper,
-so Tiny it lost the "t").  This will print the C<.perl> representation plus
-some extra information that could be introspected, of the given variables on
-STDERR:
+There is also a Rakudo-specific debugging aid for developers called C<dd> (Tiny
+Data Dumper, so tiny it lost the "t").  This will print the C<.perl>
+representation plus some extra information that could be introspected, of the
+given variables on STDERR:
 
 =begin code :preamble<no strict;> :ok-test<dd>
 # Perl 6

doc/Language/regexes.pod6

@@ -6,7 +6,7 @@
 
 X<|Regular Expressions>
 
-Regular expressions, regexes for short, are a sequence of characters that
+Regular expressions, I<regexes> for short, are a sequence of characters that
 describe a pattern of text. Pattern matching is the process of matching
 those patterns to actual text.
 
@@ -1383,9 +1383,11 @@ A named regex can be declared with C<my regex named-regex { body here }>, and
 called with C«<named-regex>». At the same time, calling a named regex
 installs a named capture with the same name.
 
-To give the capture a different name from the regex, use the
-syntax C«<capture-name=named-regex>». If no capture is desired, a
-leading dot will suppress it: C«<.named-regex>».
+To give the capture a different name from the regex, use the syntax
+C«<capture-name=named-regex>». If no capture is desired, a leading dot or
+ampersand will suppress it: C«<.named-regex>» if a regex declared in the same
+lexical context is used, C«<&named-regex>» if it is a method declared in the
+same class or grammar.
 
 Here's more complete code for parsing C<ini> files:
 
@@ -1461,12 +1463,12 @@ Note that the first two syntax interpolate the string lexically, while
 C«<$pattern>» and C«<{$pattern.method}>» causes L«implicit EVAL|
 /language/traps#<{$x}>_vs_$($x):_Implicit_EVAL», which is a known trap.
 
-When an array variable is interpolated into a regex, the regex engine handles
-it like a C<|> alternative of the regex elements (see the documentation on
-L<embedded lists|#Quoted lists are LTM matches>, above).  The interpolation rules for
-individual elements are the same as for scalars, so strings and numbers match
-literally, and L</type/Regex|Regex> objects match as regexes. Just as with
-ordinary C<|> interpolation, the longest match succeeds:
+When an array variable is interpolated into a regex, the regex engine handles it
+like a C<|> alternative of the regex elements (see the documentation on
+L<embedded lists|#Quoted lists are LTM matches>, above).  The interpolation
+rules for individual elements are the same as for scalars, so strings and
+numbers match literally, and L</type/Regex|Regex> objects match as regexes. Just
+as with ordinary C<|> interpolation, the longest match succeeds:
 
     my @a = '2', 23, rx/a.+/;
     say ('b235' ~~ /  b @a /).Str;      # OUTPUT: «b23»
@@ -1475,16 +1477,17 @@ The use of hash variables in regexes is preserved.
 
 =head2 Regex Boolean condition check
 
-The special operator C«<?{}>» allows the evaluation of a boolean expression that can perform
-a semantic evaluation of the match before the regular expression continues. In other words, it is possible
-to check in a boolean context a part of a regular expression and therefore invalidate the whole match (or allow it
-to continue) even if the match succeeds from a syntactic point of view.
+The special operator C«<?{}>» allows the evaluation of a boolean expression that
+can perform a semantic evaluation of the match before the regular expression
+continues. In other words, it is possible to check in a boolean context a part
+of a regular expression and therefore invalidate the whole match (or allow it to
+continue) even if the match succeeds from a syntactic point of view.
 
 In particular the C«<?{}>» operator requires a C<True> value in order to allow the regular expression to match, while its
 negated form  C«<!{}>» requires a C<False> value.
 
-In order to demonstrate the above operator, please consider the following example that involves
-a simple IPv4 address matching:
+In order to demonstrate the above operator, please consider the following
+example that involves a simple IPv4 address matching:
 
 =begin code
 my $localhost = '127.0.0.1';
@@ -1493,11 +1496,12 @@ $localhost ~~ / ^ <ipv4-octet> ** 4 % "." $ /;
 say $/<ipv4-octet>;   # OUTPUT: [｢127｣ ｢0｣ ｢0｣ ｢1｣]
 =end code
 
-The C<octet> regular expression matches against a number made by one up to three digits. Each match
-is driven by the result of the C«<?{}>», that being the fixed value of C<True> means that the regular
-expression match has to be always considered as good.
-As a counter-example, using the special constant value C<False> will invalidate the match even if the
-regular expression matches from a syntactic point of view:
+The C<octet> regular expression matches against a number made by one up to three
+digits. Each match is driven by the result of the C«<?{}>», that being the fixed
+value of C<True> means that the regular expression match has to be always
+considered as good. As a counter-example, using the special constant value
+C<False> will invalidate the match even if the regular expression matches from a
+syntactic point of view:
 
 =begin code
 my $localhost = '127.0.0.1';
@@ -1506,8 +1510,9 @@ $localhost ~~ / ^ <ipv4-octet> ** 4 % "." $ /;
 say $/<ipv4-octet>;   # OUTPUT: Nil
 =end code
 
-From the above examples, it should be clear that it is possible to improve the semantic check, for instance
-ensuring that each I<octet> is really a valid IPv4 octet:
+From the above examples, it should be clear that it is possible to improve the
+semantic check, for instance ensuring that each I<octet> is really a valid IPv4
+octet:
 
 =begin code
 my $localhost = '127.0.0.1';
@@ -1516,8 +1521,8 @@ $localhost ~~ / ^ <ipv4-octet> ** 4 % "." $ /;
 say $/<ipv4-octet>;   # OUTPUT: [｢127｣ ｢0｣ ｢0｣ ｢1｣]
 =end code
 
-Please note that it is not required to evaluate the regular expression in-line, but also a regular method can be
-called to get the boolean value:
+Please note that it is not required to evaluate the regular expression in-line,
+but also a regular method can be called to get the boolean value:
 
 =begin code
 my $localhost = '127.0.0.1';
@@ -1527,7 +1532,8 @@ $localhost ~~ / ^ <ipv4-octet> ** 4 % "." $ /;
 say $/<ipv4-octet>;   # OUTPUT: [｢127｣ ｢0｣ ｢0｣ ｢1｣]
 =end code
 
-Of course, being C«<!{}>» the negation form of C«<?{}>» the same boolean evaluation can be rewritten in a negated form:
+Of course, being C«<!{}>» the negation form of C«<?{}>» the same boolean
+evaluation can be rewritten in a negated form:
 
 =begin code
 my $localhost = '127.0.0.1';