[perl #126971] [BUG] Rematching in a code assertion inside a regex doesn't recognize Match variable shorthands

[via RT]

# New Ticket Created by  Pepe Schwarz 
# Please include the string:  [perl #126971]
# in the subject line of all future correspondence about this issue. 
# <URL: https://rt.perl.org/Ticket/Display.html?id=126971 >


02:03 < lucs> m: say so("a" ~~ / (.) <?{ $0 ~~ /'a'/ && say("\$0 is now ", 
$0.WHAT) }> /)
02:03 <+camelia> rakudo-moar 091ee7: OUTPUT«$0 is now Nil␤True␤»
[...]
02:05 < lucs> TimToady: So would that ^^ be a bug or a don't-do-that?
[...]
02:06 < psch> m: say so("a" ~~ / (.) <?{ $0 ~~ /'a'/ && say("\$/ is now ", 
$0.WHAT) }> /)
[...]
02:06 <+camelia> rakudo-moar 091ee7: OUTPUT«$/ is now Nil␤True␤»
02:06 < psch> huh
02:06 < psch> that seems wrong to me, at least
02:06 < psch> well, no
02:07 < psch> accessing $/ there is a "works sometimes" workaround for 
accessing the CURSOR special name
[...]
02:07 < psch> m: say so("a" ~~ / (.) <?{ $0 ~~ /'a'/ && say("\$¢ is now ", 
$¢.WHAT) }> /)
02:07 <+camelia> rakudo-moar 091ee7: OUTPUT«$¢ is now Nil␤True␤»
[...]
02:08 < psch> m: say so("a" ~~ / (.) <?{ $0 ~~ /'a'/ && say("\$/ is now ", 
$/.WHAT) }> /)
02:08 <+camelia> rakudo-moar 091ee7: OUTPUT«$/ is now (Match)␤True␤»
[...]
02:08 < psch> m: say so("a" ~~ / (.) <?{ $0 ~~ /'a'/ && say("\$/[0] is now ", 
$/[0].WHAT) }> /)
02:08 <+camelia> rakudo-moar 091ee7: OUTPUT«$/[0] is now Nil␤True␤»
02:08 < psch> lucs: the hunch is that the switch from Perl6::Grammar to 
NQP::P6Regex messes something up with accessing the different
              interpretations of $/
02:09 < psch> as in, the code block inside the regex doesn't build the same 
lookup for $0 as it would outside of a regex
[...]
02:09 < psch> that might easily be wrong though, but the fact that $/ is Match 
seems to hint at it...
[...]
02:11 < psch> 'cause even if $/ isn't supposed to work there (which ISTR it 
isn't), at least $¢ should

In case of bad editing refer to 
http://irclog.perlgeek.de/perl6/2015-12-20#i_11746338 and onward.

The underlying issue seems to be that the special name $/ retains some kind of 
Match object when referenced inside any kind of code assertion inside of a 
regex, but accessing positional captures fails. I seem to recall mention of $/ 
not necessarily being valid in a regex, but trying to access $¢ instead is 
similarly fruitless.