I'm not planning on putting it in there, because it's one of those things that programmers use as an excuse. "Oh, I can't afford a stack, I need my code to go quickly. Even if it takes me longer to write. And crashes more often. And is harder to debug. And I can't use half my language features. And I'm just writing CRUD apps for my bank."
It's a last-ditch optimization for when you've got nothing else left, or perhaps in your case, something that a language designer worries about. But at the moment, I see a lot more people grossly underestimating the costs of throwing away the stack than underestimating the benefits. It's a rare program that has been so hyperoptimized that there's nothing left to do but throw away the stack, and even if you get that far, you need to understand the full import of what that means, which is actually a great deal more than just "oh, I don't have these bytes in RAM anymore".
I completely disagree. :) Stacks have a large performance cost when you get to this the last level of optimization; we're talking 2x or more in tight syscall loops when you take cache misses into account. Moreover, the memory costs of stacks compared to the most optimized state machine can easily be 10x. You may not need this level of performance, but some people do.
This leads me to the exact opposite conclusion that you have. I think that, in terms of language design, we should be figuring out how to design stackless coroutines in a way that is as ergonomic as the stackful ones instead of throwing up our hands and saying "we're going to eat this large performance cost because there's no way we can possibly design a language that makes stackless programming ergonomic and robust".
As language designers, we shouldn't be giving up before even fighting the battle. Because, if we do, nginx will be around and winning the performance fight, and people will (rightly in many cases) never switch away from it, and that old-timey C will persist forever. My former colleague Robert O'Callahan had a great view on "abstraction taxes": if your abstractions aren't zero-cost, you're incentivizing programmers to not use them, and you're forcing programmers to choose between good engineering practice and good performance.
It's a last-ditch optimization for when you've got nothing else left, or perhaps in your case, something that a language designer worries about. But at the moment, I see a lot more people grossly underestimating the costs of throwing away the stack than underestimating the benefits. It's a rare program that has been so hyperoptimized that there's nothing left to do but throw away the stack, and even if you get that far, you need to understand the full import of what that means, which is actually a great deal more than just "oh, I don't have these bytes in RAM anymore".