So you're not talking about what I was talking about, which was dealing with reality.

Were you there?

No way am I going to believe that that is a balanced characterization of what went down.

With all due respect, that's because you have no intent of reading the IRC logs or the mailing list archives of that time period. If you cared to do any research at all, you would have no trouble confirming my characterization of the event. You could start by looking at the commit rate to Parrot and correlating that with the "Rakudo doesn't want Parrot" discussions in December 2010 and January 2011 and then the Parrot commit rate going way down in February and March of 2011.

There is a correlation between those events.

"designed to be portable, with Parrot needing to evolve in to a dedicated NQP backend"

If you had bothered to do your research, you would know why that was never and would never be acceptable to Parrot.

It's sad that you can't be bothered, that you're so invested in propping up a project categorized by overpromising, underdelivering, and failure after failure that you're willing to take the sunshiney optimism of the people who were paid to work on the project over the opinion of dozens of volunteers who've been burned out or forced out of the project because they could no longer buy into the repeated promise that usable and useful software is just another six months away.

If you were truly interested in the truth, you'd ask the other people involved about their characterization of events.

You might start with a pointed question:

When Patrick and Jonathan said that they were going to rewrite NQP again to focus on VM independence because that independence was "important to the long term plans of Rakudo", what was your reaction?

Given that:

• Rakudo Star was less than a year old at that point
• Everyone acknowledged that that rewrite of NQP would mean a huge regression in the featureset of Rakudo on the rewrite branch
• Almost everyone acknowledged that development effort would necessarily be split between supporting the existing, working codebase and the rewrite
• If the rewrite went well, that would mean abandoning the existing development branch (the one on which Rakudo Star was based), which meant abandoning any users who'd tried to build anything with Star releases

... is it so difficult for you to conceive of a world in which volunteers would think that that circus of bungling was anything they'd like to participate in?

You know what's also sad? The fine whine of unrealistic expectations from Rakudo that Parrot could simultaneously provide a stable API (despite Rakudo reaching into the guts of Parrot) and meet every performance and feature goal of Rakudo, instantly updating Rakudo about any breakages, writing patches for Rakudo that they could apply when they saw fit, never actually testing Rakudo code against Parrot (that was Parrot's job, to test all external clients), and support existing abandonware that Rakudo had convinced people to import into the Parrot repository. With volunteer labor. To support a Rakudo project that had no qualms about breaking stuff their users had written or depended on—no qualms about not even testing that Rakudo broke stuff in its library or ecosystem.

So, yeah, when Rakudo said "The long term support plan of running on multiple VM backends is so important that we're going to break everything right now, less than a year after Rakudo Star came out, and spend a year getting us back to the place we are right now instead of passing more spec tests or writing documentation or making stable and useful packages or testing the ecosystem or anything else that actually gets a useful and usable P6 into the hands of real users," I think you'd have to be quite a fool to imagine that that was motivated by anything other than "We don't want to use Parrot anymore." I certainly wouldn't spend two and a half years not delivering working software unless I had a goal I considered more important.

After all, it's not as if most of the Rakudo developers making this choice lacked commit access to Parrot. (If you're in the mood for grim amusement, look at the commit history to see who wrote the long-lamented Parrot object system.)

Patrick's utterly compelling logic

Post hoc ergo propter hoc. Parrot had its problems. Everyone agrees on that—but when the paid developers of Rakudo told the volunteers of Parrot (volunteers who'd worked on Parrot for years because they wanted to help realize a usable and usefl P6) that Parrot had no place in Rakudo, what did you expect to happen?

Don't take my word for it. Ask Dan. Ask Allison. Ask Jesse. Ask Nat. Ask Andrew. Ask Julian. Ask Vasily.