>
> You can already customize the promise type based on the signature of the
> coroutine signature by specializing std::coroutine_traits.
> See example at
> https://en.cppreference.com/w/cpp/coroutine/coroutine_traits
> <https://en.cppreference.com/w/cpp/coroutine/coroutine_traits>
>

I know, but for me that only seems like a clumsy helper construction
that is only needed because of a missing co_init operator.
For my case, using a traits class could not solve the problem either.
I try to describe what problem I faced:

I have an unified I/O framework that offers several functions like:

IoHandle do_something(blablabla args....);

ALL functions return an opaque IoHandle that offers methods like
process(), check_for_completion(), cancel() or wait(), their
implementation highly depending on the type of I/O actually being
processed in the background.

Now, I tried to add coroutines there to be able to compose I/Os from
several sub-I/Os with pieces of code executed in between them when
someone calls process() or wait() on the IoHandle - that seems like a
classical use case of coroutines!

So, what I clearly see here is that IoHandle must be able to encapsulate
  a coroutine handle while the promise_type bound to these handles is
completely implementation-specific and thus an implementation detail of
the I/O routine I implemented.

Unfortunately, this cannot be achieved, even when using type traits,
because I have several I/O methods with identical parameters and all
returning "IoHandle", thus all having identical signatures, but actually
having completely different implementations under the hood requiring
different promise types.
So, how should I hide occasional coroutine functionality there if I'm
forced to bound the promise_type to the function signature (or even the
return type when a traits class is not in use)?
Note that such coroutine must even be able to implement an override of a
virtual function of some runtime interface definition.

The solution I proposed solves all these problems.