I am still enthusiastic about coroutines in Rust and want to reduce barriers to making progress.
I do think a friendly fork is a good solution. Even if we don’t add support for coroutines to mainline Rust in the near future, it is totally feasible to implement a library that looks like std, but built on top of coroutines, and we should want to make that happen. To make this possible is one of the reasons we’ve worked so hard to subdivide std into reusable pieces already.
We need to figure out how you can experiment with a coroutine-std out of tree that shares much of the code with std, but doesn’t impose a great burden on the std maintainers.
Refactoring std could be a part of the story here. So could config-specific compilation scenarios.
Edit: based on the two above links, the way I imagine a fully-couritinified Rust working at a high level is that std is implemented on top of a platform abstraction layer (std-pal) that already has a rough definition in std today. Coroutine-Rust implements it’s version of std-pal that stock std links to, and simultaneously enables a global feature flag indicating that the entire world is compiled with coroutine support. The ecosystem can slowly be audited for compatibility and opt into this world with a yet-undesigned mechanism. Although that doesn’t allow you to mix coroutine-Rust with regular Rust, it seems like a good direction to head in that’s well aligned with existing goals.