A different runtime wouldn't be able to make the compiler use a different stack allocation strategy (like Go's segmented stacks), for that the compiler needs to

A different runtime wouldn't be able to make the compiler use a different stack allocation strategy (like Go's segmented stacks), for that the compiler needs to know what you're doing. Even if they also did that via having two ABIs for every platform (green vs native) it would essentially bake in a particular runtime as you wouldn't be able to experiment with these lower level primitives, only how you interface with them. If they ever define a stable ABI having two ABIs depending on thread type would also fragment the ecosystem at least as bad as the async runtimes do. As far as async runtime fragmentation you can write code that is generic across runtimes, it's just less convenient to use. If your code only works with plain data and futures you're fine on any runtime, it's when you want to spawn new tasks or block on a task that you have to have a runtime dependency. Async vs sync is the classic "what color is your function" problem which green threads kind of solves but not completely so you still have to understand what is happening so you don't stall every task on a native thread with CPU heavy or blocking work.