The problem is that the current nextTick semantics are terrible. We cannot keep it as it is forever.
The use cases provided in opposition to this change are very bad ideas. In all of the cases presented, what you actually want is either a separate thread of execution or an idle listener; *not* a maximum-priority scheduled task in the current thread. People sometimes use setTimeout(fn,0) in the browser for CPU-intensive operations, **because there is no other choice**, but even in those cases, it's better to use WebWorkers instead, now that they are pretty widely supported. The bugs we're seeing in node-core are not just in node-core. Any library that uses nextTick for its *intended purpose*, to defer execution until after the current run-to-completion, but before normal-priority IO events have a chance to fire, will find that they have the same sporadic bugs at scale. No kittens will die from this change. What will happen is that a few terrible abuses of nextTick will perhaps behave slightly more badly. And even there, we could probably set it up so that nextTicks added in the nextTick phase are deferred until later. No one's dug into the code to try and do this, and it's not scheduled until after 0.8 anyway, so it's all vaporware at this point. The real source of this problem is that the concept of a "tick" is pretty loosely defined in Node, and not very well understood. As a result, a lot of people have come up with their own (mostly wrong) beliefs about how it works, and have built libraries around those beliefs. The semantics are too complicated to get right all the time, and we're seeing the results of that. You can't please everyone. We're going to fix node so that it's better at its primary focus. If you're using nextTick for CPU-intensive operations, it's already terrible, and it's going to get worse, so stop that; use a child process. If you're using it as an idle-listener, it's not that, so stop; setTimeout is better (since it's lower priority and abuses the CPU less badly). Adding setImmediate is not out of the question, but is far from decided. We're not going to keep the current terrible complicated only-fails-in-production nextTick semantics, and then further confuse things by adding an "afterTick" that actually works.
