zones.js, async_hooks, and low-level primitives #31727

Hello folks,
I'm currently working on a visualisation / developper tools experiment to help tackle the issues of time / memory multiplexing in long-running JS apps (Node HTTP servers, web apps, native apps programmed in JS). I'm by no means an expert in systems, scheduling or JS spec/engines, but I've encountered very tedious related bugs in production and this is me trying to prevent them.

I've done some work based upon the new async_hooks API, which raises interesting questions and has led me to think that what I need is a primitive to handle continuation with context between async stack frames scheduled using the host environment I/O APIs (eg. fs.readFile, window.requestAnimationFrame), host event loop scheduling APIs (http.createServer, window.addEventListener), and JS scheduling APIs (eg. new Promise, async/await).

Such a primitive would allow us to build more advanced multiplexing primitives (eg. coroutines, algebraic effects, actors...).
I believe that async_hooks allows us to do something very close to this in Node, and that zones.js has done an amazing work around the same ideas.

My current prototype is very crude and I think that async_hooks allows us to detect/visualize issues but not to prevent them at runtime. However, this alone could help us catch bugs in dev/test phase and certainly be an improvement from the current situation. Signaling a bug is not preventing it but at least it doesn't creep until it blows in your face the way leaking Promises/requestAnimationFrame do.

Would it make sense to work on a base implementation/polyfill that would expose similar low-level primitives both in Node (using async_hooks) and in the browser (using globals monkey-patching)? Could zones.js be implemented in terms of such a primitive? Could the monkey-patching part of zones.js be used as part of the implementation?