From @peschwa

Consider the following two snippets​:

21​:03 <psch> m​: .<A B C> >>=>> True given my %h; dd %h
21​:03 <camelia> rakudo-moar 0b8e08​: OUTPUT«===SORRY!=== Error while compiling
  /tmp/yQ1mgyWhDJ␤Missing << or >>␤at /tmp/yQ1mgyWhDJ​:1␤------>
  .<A B C> >>=>⏏> True given my %h; dd %h␤ expecting any of​:␤
  infix␤ infix stopper␤»

21​:09 < psch> m​: .<A B C> »=» True given my %h; dd %h # actually, never mind
21​:09 <+camelia> rakudo-moar 0b8e08​: OUTPUT«Hash %h = {​:A, :B, :C}␤»

I would expect both to behave identically, considering the equivalence between >>=>> and »=».

From @TimToady

Not A Bug.

LTM requires it to recognize => over = inside, and then you're missing a >. Looking at it from the other direction, thinking that it will find the >> on the end and then back up to isolate the = is a subtle mental trap of two-pass parsing, which is typically forbidden in Perl 6. To write the Texas form of this operator, you must write >>[=>]>> instead.

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

@TimToady - Status changed from 'open' to 'rejected'

From @TimToady

On Fri Apr 22 15​:38​:22 2016, larry wrote​:

Not A Bug.

LTM requires it to recognize => over = inside, and then you're missing
a >. Looking at it from the other direction, thinking that it will
find the >> on the end and then back up to isolate the = is a subtle
mental trap of two-pass parsing, which is typically forbidden in Perl
6. To write the Texas form of this operator, you must write >>[=>]>>
instead.

Oops, make that >>[=]>> instead