I think this may be a dubious test rather than a Rakudo bug.
For reference, the code tested by the fudged test in question boils down to this:
➜ say "abbb" ~~ m:ex/"a" b+/;
(｢abbb｣ ｢abb｣ ｢ab｣)
The test then checks if the first element of the result is "ab", and the second is "abb" - which is not the case because they are returned in the opposite order.
Why is the test assuming that the results with the same starting position have to be returned in a specific order? S05 specifically states that the order is not defined in such a case:
The matches are guaranteed to be returned in left-to-right order with respect
to the starting positions. The order within each starting position is not
guaranteed and may depend on the nature of both the pattern and the matching
engine. (Conjecture: or we could enforce backtracking engine semantics. Or we
could guarantee no order at all unless the pattern starts with "::" or some
such to suppress DFAish solutions.)
(FYI: Rakudo's current behavior seems to implement the "enforce backtracking engine semantics" conjecture.)
It looks to me like the test should sort the results, before checking that the first two are "ab" and "abb".
#Fri, 06 May 2016 10:33:34 -0700The RT System itself - Status changed from 'new' to 'open'
#Fri, 06 May 2016 10:35:32 -0700Sam S. <email@example.com> - Subject changed from '[BUG] exhaustive capture too greedy' to '[BUG] exhaustive capture too greedy (Or bogus test?)'
#Fri, 06 May 2016 10:35:33 -0700Sam S. <firstname.lastname@example.org> - Tag Bug deleted