> When Rakudo announced it wanted to rewrite NQP to run on multiple backends
What announcement are you speaking of? In the past you seem to have suggested they announced this in late 2010 or early 2011. Available public evidence, including a github repo, makes it clear that one of the primary objectives of the 2009 NQP rewrite was to transition to a multiple backend architecture, and there was no attempt to hide this.[1]
There were discussions in early 2011 about the next stage in the multi backend evolution, and about elements of Rakudo's latest NQP becoming a central part of Parrot, and this did seem to get derailed by misunderstandings about NQP's support for multiple backends. Maybe that's what you're talking about?
> First, because Parrot developers didn't treat Rakudo as the most important hosted language.
Patrick's stated justification for a multiple backend Rakudo is explicitly grounded in Larry's 2001 specification that Perl 6 must run on existing major VMs[2] and Patrick's decision when he became the Perl 6 project manager in June 2009 to prepare Rakudo to run on JVM and CLR.[1]
That said, by the time Rakudo moved out of the Parrot repo in early 2009 there were definitely major problems with the way Parrot and Rakudo dev meshed (or not)[3] so it might have been good if Parrot had treated Rakudo as an important hosted language, or at least had better responded to what Rakudo actually asked for, according to the mailing lists and IRC logs from 2009 thru 2011, namely for there to be better management of breakage.[4]
> Second, because Parrot didn't provide the features Rakudo wanted
Again, aiui, this wasn't a stated justification for Rakudo considering multiple backends before 2009 nor was it when Patrick rewrote NQP with support for multiple backends in 2009.
But, yes, the growing gap between what Rakudo was saying it needed from Parrot and what Parrot actually provided must surely have led Patrick and jnthn to ponder a plan B, and spending a few years writing another VM would have been a natural thing to consider in the midst of the deteriorating Parrot situation in 2011 despite the very scary prospect of yet another huge delay in getting P6 to 6.0.
> I interpret {Rakudo's} response as something other than good faith. I believe that's why Parrot developers left; there's no point to sticking around in that situation.
There were indeed clear signs of a severe breakdown in trust littered throughout 2011.
I think jnthn and especially Patrick really tried to solve this problem but were fighting a losing battle. I acknowledge my bias (I like Patrick and jnthn) but there are tons of examples such as Patrick drafting a formal Parrot/Rakudo relationship policy in mid 2011:
http://lists.parrot.org/pipermail/parrot-dev/2011-July/00598...
(Note that there was no reply.)
I agree there would be no point in folk continuing to cooperate if there's an assumption of bad faith. Typically if person/group A interprets person/group B's actions as being done in bad faith, person/group A themselves starts acting in bad faith, or at least in a non-cooperative manner. If this attitude spreads throughout a group then all is indeed lost.
----
[1] The two Rakudo devs who matter in this context are Patrick and jnthn.
Patrick Michaud's 2013 "Perl on JVM" talk made it clear that one of the goals of his 2009 NQP rewrite was to restructure it to support multiple backends corresponding to existing major VMs (with JVM and CLR specifically in mind).
https://www.youtube.com/watch?v=XgPh5Li3k4g
Googling for rakudo multiple backends with a date filter and then doing a quick archive.org dig shows that sometime in 2009 jnthn changed the "What do I do in Perl 6?" section of his about page to include "Transforming Rakudo from a single backend compiler to one capable of targetting multiple backends".
http://web.archive.org/web/20091218092004/http://jnthn.net/p...
[2] "Perl 6 must not be limited to running only on platforms that can be programmed in C. It must be able to run in other kinds of virtual machines, such as those supported by Java and C#." from http://www.perl.com/pub/2001/04/02/wall.html
[3] http://www.nntp.perl.org/group/perl.perl6.compiler/2009/01/m...
[4] http://comments.gmane.org/gmane.comp.compilers.parrot.devel/...
http://lists.parrot.org/pipermail/parrot-dev/2010-December/0...
https://groups.google.com/forum/#!topic/parrot-dev/nlgcpd2Xb...
http://irclog.perlgeek.de/parrotsketch/2011-09-06#i_4382083
http://lists.parrot.org/pipermail/parrot-dev/2011-September/...