At first I thought it might have to do with the bizarre static/dynamic scoping duality of the $1, $2, ... variables, since the postponed (??{CODE}) blocks may be compiled somewhere where they can't reach the correct $1, $2, .... But they also can't seem to access @- and @+, which I don't think have the same scoping properties.

And now I don't know what to think, because of the following example: I add an empty capturing group before the (??{CODE}) block in the outermost match, and it works (or at least seems to):

# This is perl, v5.8.6 built for i386-linux-thread-multi
use Data::Dumper;

$rx = qr{ (.) (?{ print Dumper $1 }) }x;
"japhy" =~ m{    (??{ $rx }) }x;
## $VAR1 = undef;

$rx = qr{ (.) (?{ print Dumper $1 }) }x;
"japhy" =~ m{ () (??{ $rx }) }x;
## $VAR1 = 'j';
[download]

If you were to dump @- and @+ from inside the first example, you'd see that @- has two entries, but @+ has one. It's as if $1 was only partially "set up"..

Now I don't know if this "workaround" helps you or not. It could probably allow you to write the parser closer to how you originally envisioned. But it seems like a more fragile workaround than the one you have, and I'm not sure how much I trust it. I think I remember seeing similar weirdness with capturing parens somewhere else, but I can't find the reference at the moment.

Then there's the fact that doing this with a regex is silly, when you could write a RecDescent grammar in about 5 seconds.. but I know you know that ;)