We already have stackful coroutines. They're called threads. If for some reason you want M:N threading, we have that too, via the mioco library. (If you think mioco's M:N threading will provide far superior performance to regular 1:1 threads, though, you will probably be disappointed.)
If you look at the performance numbers of these approaches, you'll see why stackless coroutines are desired.
I would also mention https://github.com/edef1c/libfringe which pretty much solves context-switches (by replacing them with compiler-generated minimal stack spills/restores).
But as you might be able to tell from their APIs, you still have to allocate stacks somehow.
I want stackfull coroutines, with custom, fast user space scheduling and task switching with guaranteed optimisation to a single stack frame and no allocation where possible.
I also want the ability to convert internal iterators to internal iterators with no overhead and even (especially) if the internal iteration function has not been specifically marked (i.e. no red/blue functions).
> guaranteed optimisation to a single stack frame and no allocation where possible
You are literally describing stackless coroutines. And the generator state transform is that optimization.
If you want to get this without using generators explicitly, it's still stackless coroutines just not how Rust supports stackless coroutines. There was some discussion about making it more implicit but no progress was made in the implicit direction.
Very much not. I want first class stackful continuation semantics that behave as stackless in at least all (but ideally more) scenarios where a stackless continuation would.
If you look at the performance numbers of these approaches, you'll see why stackless coroutines are desired.