Matthias,

Thanks a lot for such a detailed write-up!  I now better understand how you want to use the proposed API in Trio, and why the weakref approach isn't going to work (at least not in a straightforward way).

>> 2. What if another framework (say asyncio that you want to interoperate with) calls "sys.set_unawaited_coroutine_tracking(False)"?  

>> The API you propose has the *same* pitfall that 'sys.set_coroutine_wrapper()' has, when used by several frameworks simultaneously.

> As far as I understand you'll need to yield back to the other framework at some
> point. Then it's IMHO to the author to make sure to save the state of
> `sys.collect_unawaited_coroutines()`, set
> `sys.set_unawaited_coroutine_tracking(enabled: bool)` to what the other
> framework expect, and  do the opposite when they get control back. 

Who do you refer to, when you say "author"?

In any case, in my opinion, it doesn't matter.  `sys.set_coroutine_wrapper` controls a single thread-local setting, `sys.set_unawaited_coroutine_tracking` *also* controls a single thread-local setting.  Both of them have the exact same problem when there's more than one user of the API.  So we can't consider this as a strong argument in favour of the 'set_unawaited_coroutine_tracking' API.

We can fix asyncio to manage coroutine wrappers more responsively.  Right now it will raise an error if there's a wrapper set by another framework.  Ideally, event loops should get the current wrapper, set their own, and then restore the original wrapper when they are done.

With that all in mind, my question is: have you guys tried to write a wrapper object in C for coroutines (or you can use Cython to get an idea)?  You can have a freelist of such objects to make their instantiation super cheap.  And you only need to proxy the '__await__' method (tp_as_async.am_await).