From @masak

<colomon> rakudo​: sub xyz(Mu $x) { say ~$x; }; xyz(<a b c>);
<p6eval> rakudo 4fc3af​: OUTPUT«3␤»
<pmichaud> ah-ha
<masak> wut?
<pmichaud> parcels aren't stringifying properly.
<colomon> rakudo​: sub xyz(Mu $x) { say $x.WHAT; }; xyz(<a b c>);
<p6eval> rakudo 4fc3af​: OUTPUT«Parcel()␤»
<pmichaud> rakudo​: sub xyz(Mu $x) { say ~$x }; xyz(('a', 'b', 'c'));
<p6eval> rakudo 4fc3af​: OUTPUT«3␤»
* masak submits rakudobug
<pmichaud> colomon++
<pmichaud> rakudo​: say PARROT(<a b c>);
<p6eval> rakudo 4fc3af​: OUTPUT«Parcel␤»

From @masak

<colomon> btw, masak​:
<colomon> rakudo​: say (1, 2, 3)
<p6eval> rakudo d4be43​: OUTPUT«3␤»
<colomon> already reported?
<masak> o.O
<masak> no.
* masak submits rakudobug
<masak> rakudo​: say (1, 2, 3)
<colomon> I tried fixing it, and it was a mini-disaster
<p6eval> rakudo d4be43​: OUTPUT«123␤»
<colomon> rakudo​: say (1, 2, 3).Str
<p6eval> rakudo d4be43​: OUTPUT«1 2 3␤»
<masak> strange that only prefix​:<> is broken.
<colomon> agreed.
<colomon> So strange, in fact, that I initially didn't even bother to
test .Str, assuming that writing Parcel.Str would fix the problem.
<masak> rakudo​: say ~(4,5,6)
<p6eval> rakudo d4be43​: OUTPUT«3␤»
<masak> ok, so it's length, not last element.
<masak> probably stringifies the numification or something.

From @moritz

Fixed in b1fd5d8e5dc8fdc67fffc003266c78ed8c5515c2 and tested in parcel.t

The RT System itself - Status changed from 'new' to 'open'

@moritz - Status changed from 'open' to 'resolved'