> The main thing is that obviously, you have to worry about the capture lifetime yourself
This is a big deal! The fact that the coroutine frame is kept alive and your state can just stay in local variables is one of the main selling points. I experienced this first-hand when I rewrote callback-style C++ ASIO code to the new coroutine style. No more [self=shared_from_this()] and other shenanigans!
The whole point of controlling the capture is controlling the memory layout, which is what C++ is all about.
Even with Asio, you don't really have to do this. It's just the style the examples follow, and Asio itself isn't necessarily the best design.
The default behaviour of many asynchronous systems is to extend the lifetime of context data until all the asynchronous handlers have run. You can also just bind them to the resource instead which is arguably more elegant, but which depends on how cancellation is implemented.
In a coroutine everything can just live on the stack because the stack frame itself is kept alive across the asynchronous function calls.
Don't you see the big difference regarding lifetime management?
Close the socket, all handlers are cancelled, context can be freed immediately. The socket owns the data.
What if there's more than one socket involved?
Resource ownership management 101.
``` int f() { a; co_yield r; b; co_return r2; } ```
this transforms into
``` auto f(auto then) { a; return then(r, [&]() { b; return then(r2); }); }; ```
You can easily extend this to arbitrarily complex statements. The main thing is that obviously, you have to worry about the capture lifetime yourself (coroutines allocate a frame separate from the stack), and the syntax causes nesting for every statement (but you can avoid that using operator overloading, like C++26/29 does for executors)