Speaking of which, I would love to see a follow-up presentation from littledan to that “Things should layer” presentation.

Relatedly, someone should a presentation later this year about developer-convenience APIs, when we (especially engines) want to add them, and how we should triage them. I’ve seen multiple people talk about the general problem of developer-convenience APIs in core ES over the past months.

IIRC, the two big contentions with cancellation were:

• A few delegates wanted a transparent (or semi-transparent) cancellation mechanism. IMO, this was a footgun, but is solvable in user-code with AsyncContext.
• AbortController/AbortSignal was fast-tracked and shipped while we were still discussing cancellation.

I still contend that AbortController/AbortSignal is a very broken cancellation mechanism.

AbortController/Signal have a number of issues:

• Dependence on EventTarget
• Poor separation of concerns
• Privileged signaling for natives vs user-defined cancellation
• User-defined cancellation can be triggered multiple times (i.e., if you forget { once: true })
• User-defined cancellation leaks
• Composition leaks

IMO, poor separation of concerns is the worst offender:

const ctl = new AbortController();
f1(ctl.signal);
f2(ctl.signal);

function f1(signal) {
  signal.addEventListener("abort", () => { ... }, { once: true });
}

function f2(signal) {
   ...
   signal.dispatchEvent(new Event("abort")); // triggers user cancellation w/o access to controller
}