Nail down semantics of <( )> inside quantifier

[masak]

<masak> rn: say "1a23b45c6" ~~ / [ \d <( <[abc]> )> \d ]+ /
<camelia> rakudo 223075: OUTPUT«｢c｣␤␤»
<camelia> ..niecza v24-95-ga6d4c5f: OUTPUT«｢a｣␤␤»
<masak> I would like to make a case for the correct reply here being ｢abc｣.
<masak> thoughts?
<jnthn> :/
<jnthn> Not sure how that'd work
<masak> the fact that Rakudo and Niecza disagree is interesting on its own.
<masak> OK, let's start with the conservative option, then: the above is disallowed.
<masak> or, more generally, <( )> inside a quantifier is disallowed.
<jnthn> Thing is, quantified things typically result in an array
<jnthn> But here we're talking about the top-level Match...
<masak> yeah.
<masak> I'm pretty sure there is a wonderful, correct answer. but I don't quite see it now.
<jnthn> Which is why I'm not sure what to do...
<masak> anyway, OK if I submit rakudobug for not following the conservative option?
<moritz> IMHO we should forbid <( and )> inside a quantifier
<jnthn> masak: Maybe a spec ticket, if the spec doesn't alrady say (no, I didn't check...)
<jnthn> masak: Would prefer we file Rakudo bugs based on spec'd stuff, so spec ticket feels better to track the issue, 
        then file a Rakudo one when the spec one is resolved.
<masak> jnthn: gotcha. filing.
<jnthn> I just looked through all mentions of <( in S05 and don't see any wording on it being inside a quantified thingy.
<moritz> or more general
<moritz> repeated use of <(
<moritz> nr: say 'abc' ~~ /a<(b<(c/
<camelia> niecza v24-95-ga6d4c5f: OUTPUT«｢bc｣␤␤»
<camelia> ..rakudo 223075: OUTPUT«｢c｣␤␤»
<moritz> same problem
<moritz> niezca takes the first one, rakudo the last one
<FROGGS> nr: say 'abc' ~~ /a)>b<(c/
<camelia> rakudo 223075: OUTPUT«#<failed match>␤»
<camelia> ..niecza v24-95-ga6d4c5f: OUTPUT«Unhandled exception: System.ArgumentOutOfRangeException: Cannot be negative. [...]