And does it really need to? In the first release?

Personally, I think not. From my perspective PDD 25 reads like nobody could make up their mind which were important, so they opted for them all. However, I am very aware as I write, that Allison Randall is a seriously knowledgable person, and I may just be missing the point.

The problem with making the choice of concurrency model for Parrot, is the ideal of being able to support the requirements of any dynamic high level language that might sit atop it.

The really tough part about concurrency is that you cannot tack it on later with any prospect of useability or performance. It has to be accounted for in the design of every aspect of the low-level supporting infrastructure. There is no way around that. Memory management, garbage collection, IO infrastructure, even the right choice of underlying C-runtime libraries are critical to success.

And all of those choices are compounded by:

• each concurrency model you attempt to support;
• each HLL that might utilise them in novel ways;

And that's the crux of the nervous tremours I feel in my gut each time I read about what Perl 6 will do and what Parrot will support. I have expended a considerable amount thought and reading to trying to understand how to implement just one of the concurrency models mentioned, and I believe it to be extremely hard, but doable.

But trying to support them all? Trying to design a garbage collector that can support all those models of concurrency, potentially concurrently with the requirement to be able to run (say) Ruby code from within Python code from within Perl code. Will that ever be doable?