One approach would be to add a generic instrumentation API. Trio has something like this, that I think is expressive enough to let Pau implement their busyness checking as a library:
https://trio.readthedocs.io/en/latest/reference-core.html#instrument-api
This has several advantages over subclassing: multiple libraries can define their own instrumentation without interfering with each other, you don't have to redefine the instrumentation for every loop implementation, and you don't have to hook up the instrumentation when setting up the loop, e.g. you could just do something like:
import toobusy with toobusy.Monitor(loop) as monitor: if monitor.toobusy(): ...
It will help also other loops to meet the same contract making them compatibles with already implemented instruments. Maybe the major concern here is the performance penalty, do you have some numbers about how negligible is have all of these signals available to be used? -- --pau