Great post, enjoyed reading it.
This was my thinking a few years ago, when it was increasingly becoming clear free threading was going to happen.
This property of asyncio (which I keep referring to as the asyncio invariant), where programmers can reasonably expect (some) state doesn’t change between explicit suspension points, is the problem here. (Correct me if I’m wrong, f.e. Rust does not have this and Rust programmers don’t expect it.) I don’t see how the asyncio invariant can be kept in the context of M:N scheduling, but maybe this is a failure of my imagination; counter-examples welcome.
We could say all right, let’s keep using async/await while dropping the asyncio invariant. The resulting code will not be asyncio but something different; call it asyncio++. No existing asyncio library will work correctly in this context. To my mind, we’re actually introducing a third color, instead of removing coloring via virtual threads. So now, instead of needing to hunt down the asyncio version of the library you want, you need to try and hunt down the asyncio++ version. Ugh.
For this reason, I don’t see these being orthogonal.