Because, if you bother to read the language definition, you'll see that everything in the language is well-defined.

Another opportunity for the "I don't understand this so I'm going to downvote it" crowd. Another quote:

In XXX, synchronization is done on data and typically takes the form of waiting for a variable to become instantiated. Furthermore, this happens automatically: every operation that requires determined data will suspend until this data becomes determined.

XXX seems to be a very well thought out system, but it isn't Perl.

I like Perl. I like most of what I see in Perl 6. I want to be able to use threads in Perl 6. Not for the sake of using threads, but because I think that any 21st centuary language will need to be able to use threads if it is to make good use of hyperthreaded and multi-core processors and distributed processing.

But if using threads in perl is going to require messing around with horribly complex and tedious low-level syynchronisation constructs--mutexes, semaphores, etc.--then that isn't going to live up to Perl historical knack of making difficult things easy. I think I see how to make threading easy, almost transparent, within Perl.

No, I cannot guarentee it will work, but I'm doing my best to follow the idea up as best I can.

The concept is dataflow threading. Simply stated, that means that when a (shared) value is required, the requiring thread block until the providing threads provides it. But if the providing thread always blocks waiting for just one value, that is the same as a synchronous call--with the addition of a context switch. To make use of it, the requiring thread has to wait on two (or more) dataflows. That allows two thing to process, one of which will itself be in a wait state awaiting IO completion, whilst the other is calculating locally.

So the basic idea, as applied to Perl, is that whenever two, non trivial values are required at a non-serialising point in the program, parallelisation can occur. Cheaply, automatically and transparently.

Non-triviality means derived from a function or method (which could be hidden behind a tied FETCH). Non-serialising mean that both (or more) values must be required at the same point in the code. Ie, the same expression.

But, if the two values who's derivations are being parallellised are (by definition), being derived from functions (methods, tied FETCHes), then those functions will themselves often take parameters. As is, there can be no guarentee that those parameters will be evaluated in the order the programmer specifies--because EO is undefined in many cases. That puts the programmer in the position of having to serialise the derivation of those parameters. And that defeats the possibility of parallelising the functions to which those parameters will be passed, or requires elaborate additional code.

This is the point I arrived at when I asked the question in the OP. Why is EO undefined, the answer is "No good reason"-and the rest is history.