I am aware of the tension around Promise cancellation. It is difficult to get consensus on any new feature, particularly when asynchronicity is involved. With that in mind, AbortSignal(and AbortController, Event and related API's) are fundamental blocks of the DOM API that will likely never go away in the most popular Browser runtimes and even headless runtimes (Node, Deno, Bun, etc.) making them more tempting to build things on top of them. Right now, proposing any evented language concepts to Ecmascript seems to conflict with the reality that the runtimes already come with an evented system.
As such, my question is: Wouldn't it make sense and accept that EventTarget, Event, AbortController, AbortSignal are going to stick around and promote them to also become a standard in EcmaScript?
This way developers could rely on these features to be available in all runtimes and not run in compatibility issues. Also, it would be possible to add language constructs that could profit users of events.
It's possible in principle, but moving things between standards organizations is somewhat tricky: the machinery for events is complex and written in a different style than the ECMAScript specification, and not all of it would need to come over. In addition, because these were originally DOM APIs, they throw DOMException errors, and so we'd need to either specify those in ECMAScript as well or define appropriate hooks so that they could be handled by the host (I.e. HTML). No one has yet signed up to do this work.
In addition, some TC39 delegates take issue with various parts of the AbortController API and would want it improved or altered before inclusion in ECMAScript. I'm not sure how I feel about that personally but it's another stumbling block.
Thank you for the link, I did think that there must be something going on around that topic but I couldn't find it. The DOMException is truly an annoying detail.