The really-real problem that Node.js has is that once they admit that this is a good idea, huge swathes of the Node.js value proposition go flying out the window. If Javascript is not up to the task and you need a source rewriter or a really fancy, convoluted library to make non-trivial Node.js apps actually feasible to build, then... why are we in Javascript at all? Why not use a language and runtime where the support for this was baked in from day one and the compiler is the one doing all the hard work, as it should be?

This is why the Node.js hype was such a bad idea. (Don't miss the word "hype". Node.js was not a bad idea, except inasmuch as it encourages one into dangerous areas.) A useful, if limited, project built its community around a foundation of unkeepable promises. Truth is, the need to deal with this problem, and indeed far worse, the email in question should be considered an exemplar of the problem, just wait until you have three sequences of twice the size interacting with each other, is the inevitable outcome of any serious large project written in the manually-decomposed-cooperative-multiprocessing style, not an anomaly. Human brains are not meant to deal with this. It ceases to be a significant advantage over conventional threading pretty quickly.

Basically what this style comes down to is that instead of letting the runtime schedule your threads, and potentially create nondeterminism that kills your program, you manually schedule your threads instead, and instead choke the programmer on the geometric complexity of the scheduling problem. It makes beautiful small examples and demos, and makes easy things easy, but it makes hard things effectively impossible.