The most concerning issue I have with this is how easy it allows
people to make incompatible constructs.

As it currently stands, it's pretty easy to build your own
asynchronous continuation-based promise/future types in such a way
that they interact effectively with similar types from other systems.
As long as you don't have your promise interfere in the `co_await`
process, you can await on any asynchronous mechanism that will resume
your coroutine at some point in the future. The process you're
awaiting on is not required to know anything about your coroutine
machinery. And your coroutine machinery doesn't need to know anything
about what you're awaiting on.

This is *important*. It's what allows non-coroutine continuation
mechanisms to be built in a way that is compatible with `co_await`.
The networking library, future filesystem IO libraries, etc can all
use awaitable types to hide mechanisms that aren't coroutines. This
works because the basic act of awaiting is an interaction between a
type-erased coroutine handle and the type being awaited on.

That stops working once you start casting `void*`s on the assumption
that they point to some particular promise type. It's also unclear
what your call stack mechanisms expect to do when they reach root
processes like networking or filesystem operations that aren't
coroutines.

It's also unclear what you expect to do with this promise base class.
After all, there's no legal way to access the derived class. If the
base class has `virtual` functions, then it isn't standard-layout, so
it cannot be pointer-interconvertible with the derived class. And you
can't just go pointer-jumping from a subobject to the object it is a
member of. There might be some combination of byte-pointers and
`std::launder` that works, but I don't know what part of the standard
at present would make it legal.

Overall, it's not clear that your motivating examples are actually good ideas.