If the execution order is undefined, the execution may happen in parallel. Considering the rise of the multi-CPU machines, there can be a nice performance gain by not defining execution order.

Funnily enough, that is exactly where my thoughts on the subject started. I was thinking about the parallelisation of code using threads.

However, I would counter contend that if execution order is undefined and a compound statement could be transparently threaded, then, given the non-determanistic nature of threading, it would not only be impossible to guess the outcome of a compound statement--it would vary from run to run!

Indeed, if autothreading (in the threads sense rather than the P6 sense (if they are not the same thing?)), is ever going to be possible, it would be necessary to define the order of execution if the outcome of a compound statement is ever going to be predictable.

IMO, the less code relies on execution order, the clearer the code is.

Were it written down exactly when evaluation order could affect the outcome of a statement, then it would be easy to avoid it--but it isn't.

Unless you're advocating never using compound statements?

In which case, you would have to remove autoincrement, autodecrement and all the <op>= compound assignment operators from the language.