Earlier quoted context omitted.
> Every major language, or at least the ones that matter for backend development, has support for thread multiplexing / coroutines / fibers, whatever. M:N threading is not, from a developer perspective, the same thing as coroutines/fibers. Coroutines are lower-level; it's possible to build something like M:N threading on top of coroutines, but it means doing a lot of work that's already done for you in a language tha…
That's kind of the problem when the author uses meaningless words like "WEB SCALE", we don't really know what it means exactly. If it's about serving a great number of concurrent connections, I'm not sure why M:N is the only way to go.
What M:N threading does, at least in theory, is allows you to create 100,000 threads cheaply AND keep a slow function call in one thread from blocking others. In a language with those features you can build it out of continuations (NOT coroutines) and real threads. But that requires building your own scheduler that can move a user thread to a different process at need. Which is non-trivial, and is unlikely to cooperate well with any third party libraries.
That said, whether M:N threading is a real optimization depends on a ton of things. A big one is the underlying performance of the scheduler and the language. Which is improving for Perl 6..but has a long way to go.
Whether optimizing at this level matters is another good question. Most companies shouldn't care. Those that should, should be cautious about deploying Perl 6 into a mature infrastructure.
So that's why people can think that M:N is important, and why you might legitimately disagree.