The connection is that you can inefficiently simulate stackful coroutines with non-cooperative concurrency. Just give each coroutine its own OS thread, and bloc

The connection is that you can inefficiently simulate stackful coroutines with non-cooperative concurrency. Just give each coroutine its own OS thread, and block whenever the coroutine yields. It's slow and not a good way to build real systems, but the fact that it's possible at all means that libraries have to be designed to be able to handle it (e.g., that if they call into user code, it might yield the thread) and so not assume for correctness that their code will keep running in the order they control without interruption. JavaScript wasn't designed to support non-cooperative concurrency, and so a lot of existing code does assume that it's safe to, e.g., mutate global state in a way that other code doesn't expect or can't handle, run some operation, and then put the global state back how it was. Chrome's async stack traces don't undermine this because they are only for debugging; they can't in any way affect control flow. Stackful coroutines would break this assumption, the same way preemptive multithreading would. You can argue that the language should have included these features from the beginning, but it didn't, and changing it now would mess up the ecosystem.