I don't think something like this should be a thing that happens
invisibly. We're talking about a thing that fundamentally changes the
nature of where that object even gets *stored*, let alone used. You
effectively want to have an object which is stored and managed
alongside the promise object, yet is accessible by the coroutine
(unlike the promise, which the coroutine cannot easily access).

So this should be a storage qualifier, perhaps `promise_local`. Such
an object will be allocated next to the promise on the coroutine's
external stack. It's initialized after the promise and destroyed
before it is destroyed upon the coroutine's destruction.

That being said, I don't think it would be a bad idea to be able to
designate that, for a particular type, if you use a type as an
automatic, non-`promise_local` variable in a coroutine, you've made a
mistake and should get an error/warning. So we could introduce the
`[[promise_local]]` attribute. Note that this would only fire a
warning if you declare such an object in a coroutine without
`promise_local`; it would be OK to use it in non-coroutine code
without making it `promise_local`.

All that being said, I'm not convinced of the need for this feature by
the particular use case you suggest. Being able to get the current
call stack and look through would basically solve this problem.