What does Promise.withResolvers() solve and how does it replace the deferred anti-pattern?

Question presented to candidate: "Before Promise.withResolvers existed, if you needed to resolve a Promise from OUTSIDE its executor function — say, from an event listener registered elsewhere — how would you have done it? What does Promise.withResolvers actually give you that's different?"

What a strong answer should cover:

• 📌 Interview term: Promise.withResolvers() — a static ES2024 method returning a real object { promise, resolve, reject } in ONE call — verified directly: promise is a genuine Promise instance, and resolve/reject are real, working functions that settle it from anywhere.
• 📌 Interview term: the real, direct answer to the prompt's historical question — the classic pre-withResolvers "deferred" pattern: manually declaring let resolveFn, rejectFn; OUTSIDE a new Promise((res, rej) => { resolveFn = res; rejectFn = rej; }) executor, capturing them via closure — verified directly to have the IDENTICAL real shape/capability as Promise.withResolvers(), just requiring several manual lines instead of one call.
• 📌 Interview term: the real, practical use case — verified directly: resolving a Promise from inside an external, event-callback-style function (simulating an event listener registered elsewhere, entirely outside any executor) — exactly the scenario the prompt describes, confirmed working correctly.
• A precise answer names that Promise.withResolvers() does not add any NEW capability beyond the deferred pattern — both genuinely expose resolve/reject outside the executor — its real value is ergonomic: one direct call versus manually declaring, capturing, and correctly typing several separate variables.
• A precise answer names a genuinely common real use case beyond events: bridging a callback-based API (or any external system that "calls back" later) into a single Promise, without needing to wrap the ENTIRE calling code inside a new Promise executor.

Clarifying questions expected:

• None — this is a definitional/historical-technical question; directly naming and reproducing the deferred anti-pattern it replaces is the strong signal.

Code / implementation expected: Yes — real, side-by-side proof of the classic manual deferred pattern next to Promise.withResolvers()'s identical shape, plus the real external-event use case, is the clearest demonstration.