As written, the fallback also fires when the incoming id is a known window that simply didn't bind this name. Per-window bindings are a security boundary (a binding typically exposes a privileged host function to renderer content), so with this change any window can invoke another window's callback as long as the name is globally unique, including a window that was deliberately not given that binding.

Restricting the fallback to ids we've never seen still covers #35647 (the call arrives under an id bind() never registered) without letting known windows reach across:

Good catch — done in 9549d43. A known window id now matches strictly (if (callbacks) return callbacks.get(name) ?? null;); only an unknown id (the #35647 drift, where the call arrived under an id that registered nothing) falls back to the unique-name match. So a known window can no longer reach across to another window's uniquely-named callback. Added assertion #5 covering exactly that cross-reach case.

Running the real function in a V8 isolate instead of DESKTOP_JS.contains(...) is a genuine improvement over the existing tests in this file. But these markers (and the test-facing part of the comment above) ship in the binary payload that executes at startup, and marker scraping is fragile as a convention.

Consider defining resolveBindCallback in its own const RESOLVE_BIND_CALLBACK_JS: &str that gets concatenated into DESKTOP_JS, so the test can reference the constant directly with no extraction step.

Done in 9549d43. Dropped the TEST-EXTRACT markers and the extract_marked scraper. resolveBindCallback is now a resolve_bind_callback_js! macro that expands to a string literal, spliced into DESKTOP_JS via concat! and referenced directly by the test through RESOLVE_BIND_CALLBACK_JS — the test runs the exact shipped bytes with no extraction step, and nothing test-facing ships in the payload anymore.

The "known window keeps strict matching" guard only holds for windows that have called bind() at least once — a window enters windowBindCallbacks on its first bind(). A real window that never bound anything presents an id with no registry entry, so it takes this fallback and can invoke another window's uniquely-named callback. In a multi-window app where one window hosts untrusted/remote content and binds nothing, that's a cross-window escalation — and that window is indistinguishable from the drift case this fallback targets.

Seeding an empty map per window in the OrigBW wrapper would shrink the hole, but there's a more fundamental tension: the fallback exists because ev.windowId can't be trusted, yet the comment claims per-window matching on that same id is a security boundary. If the id is unreliable at this layer, a name-based fallback keyed on its unreliability weakens the boundary by construction.

ev.windowId is the routing key for every other window event too — windows.get(ev.windowId) at ~15 dispatch sites (keydown, close, focus, resize, menuclick, …). If the backend genuinely delivers a drifted id, all of those lookups silently miss as well; this fixes one of sixteen consumers.

The error-message detail in the PR body actually points at the root cause: the failure is the Deno-side No callback bound for, not the backend's No binding for — so the native registry found the binding under the incoming id. That means nativeBind.call(this, name) and event delivery agree on an id, and it's the JS map keyed by this.windowId at bind() time that diverged (stale id during construction?). I'd rather fix the id at the source — read it lazily at dispatch, or re-key when the native id settles — than fuzzy-match here. Logging both ids in the #35647 repro should pin down the mechanism.

Case 5 uses a window that bound something ("other"), so it's "known" and stays strict. The dangerous case is a real window with zero bindings: it has no registry entry, takes the fallback, and reaches win7's "ping". Worth adding that case asserting it does NOT resolve — with the current implementation it resolves, which is the gap described above.