From @masak

<sorear> rn​: say 5 Rxx rand
<camelia> rakudo 7d7df4​: OUTPUT«0.70025693867089 0.70025693867089
0.70025693867089 0.70025693867089 0.70025693867089␤»
<camelia> ..niecza v24-86-g39ab531​: OUTPUT«0.77211467026365677
0.77211467026365677 0.77211467026365677 0.77211467026365677
0.77211467026365677␤»
<FROGGS> no cookie for both
<masak> hm, sorear++ just found a bug in two implementations ;)
<masak> rn​: say rand xx 5
<camelia> niecza v24-86-g39ab531​: OUTPUT«0.62266399973196163
0.18375288144860086 0.37745106424086311 0.96518965482953456
0.73068906819945623␤»
<camelia> ..rakudo 7d7df4​: OUTPUT«0.181609341499524 0.340130289589194
0.252906549579116 0.617402868939354 0.385966828776859␤»
<masak> right.
* masak submits rakudobug
<masak> I'm just assuming that if infix​:<xx> thunks its lhs, then
infix​:<Rxx> should thunk its rhs.
<sorear> masak​: it's a very long-standing behavior of niecza that
weakly macroey operators lose their macroness when metaopped
<sorear> masak​: because metaops require a coderef
<masak> sorear​: that sounds like an argument against this being a bug.
<sorear> strongly macroey operators like := can't be metaopped at all

From @TimToady

Fixed, along with all the other metaops, in​:
1e1556b1a25bc4c73a505fdd249d4179ffc813de
0a2303c0f6a2a3782fecb13db1523cb5442467de
67202d697d3fe48b800e95262bebe6da17bfcf49
e2e23fb8853808839884f23a0b8aa91f458fd310
97ef742f350e84dae275ed2dc9d453795f057dba
6516930c86d6ff4296ee8699a64eb1315eed2583

Tests​:
200ec05eb0865b9cbc128ba77b726111cc5a171a
52e3715b882ce8f7fa9761029ce7166725eb0bee

@TimToady - Status changed from 'new' to 'resolved'