Nit: #nextToken can overflow Number.MAX_SAFE_INTEGER with enough navigations. In practice this will never happen (it would take ~9 quadrillion calls), but wrapping with modular arithmetic would be more defensive. Not blocking.

Confirming my understanding of the strict-mode interaction: in dev, React's strict mode double-invokes the render function. The first invocation calls performMpaNavigation (scheduling a delayed location.assign/replace) and then throw unresolvedMpaNavigation. React discards that render. The second invocation calls performMpaNavigation again — but the scheduler's dedup check (pendingNavigation?.href === href && pendingNavigation.historyUpdateMode === historyUpdateMode) will no-op on the identical call, so this is safe. Good.

The early scroll restoration fires via scheduleAfterFrame (one rAF) and then retries up to 60 frames. Meanwhile the pendingNavigation.finally() branch (line 58) skips scroll restoration when shouldRestoreSavedScroll is true, so the early path is the only path for saved-position restores.

Is there a risk that the navigation completes and changes the route content (potentially shrinking document height), while the early rAF-based restore loop is still trying to scroll to a now-unreachable position? The shouldContinue guard checks isCurrentNavigation, which protects against superseded navigations, but not against the content having settled at a shorter document height. The attempts >= 60 cap prevents an infinite loop, but you'd get up to 60 frames of futile scrollTo calls.

Probably acceptable given the upstream parity goal (Next.js has similar behavior), but worth flagging.

The reset() call inside startTransition is the key fix for the redirect loop. By clearing the boundary state after dispatching the navigation, React won't re-mount the page component that threw redirect() during the next render pass. This matches Next.js's redirect-boundary.tsx behavior.

The reset callback from the parent render() is a fresh arrow per render, but since HandleRedirect only renders when redirect state is set (and reset() clears it, preventing re-render with the same props), this won't cause effect re-fires in practice. Looks correct.

Good addition for Next.js parity. The exact content="noindex" string matches the upstream assertion at navigation.test.ts#L654-L660.

Good fix — moving syncServerActionHttpFallbackHead after the redirect-target check and conditioning it on hasSameUrlRerenderPayload. Previously this was called unconditionally before parsing the flight response, which would incorrectly inject noindex on 404 status even when the action returned a re-render payload. Now noindex is only injected when there's no re-render payload to replace the current page content.

The reordering (check pagesCtx first) is the correct fix for stable useParams() in Pages Router. When navigating from App Router to Pages Router, stale App Router client params could previously leak through because state.clientParams still had values from the App Router navigation. The early return on pagesCtx ensures Pages Router pages always use their own route params as the source of truth.

The useMemo deps array is [] (empty), so this adapter is created once. The methods capture Router (module-level singleton) which is correct — they're stable references.

bfcacheId is hardcoded to "0". In Next.js, bfcacheId detects bfcache restorations. Is the static value sufficient here? If the App Router entry also uses bfcacheId for bfcache detection, the static value might cause issues on Pages Router pages after a bfcache restore. Worth verifying but probably fine for initial parity.

Good addition — after location.replace/location.assign, the await new Promise<void>(() => {}) suspends the caller forever. This ensures the navigateClientSide promise never resolves, keeping useTransition's isPending true until the page unloads. Matches the MPA navigation suspension pattern used in the App Router's navigateExternal path.

Nice centralization. The _rsc search param + rsc: 1 header check is the canonical way to identify RSC requests in the new URL format. This replaces the fragile .rsc pathname suffix matching across all E2E tests.

Minor (non-blocking): the early saved-scroll path schedules retryScrollTo via scheduleAfterFrame and the retry loop runs up to 60 frames. The shouldContinue guard (isCurrentNavigation) protects against a superseded navigation, but not against the new route content settling at a shorter document height — in that case window.scrollTo(x, y) can never reach y and the loop burns all 60 frames clamping to the max scrollable position before giving up. This is acceptable for upstream parity (Next.js retries similarly), just flagging so it's a conscious choice rather than an oversight.

The parts.slice(2, -2).join(";") rejoin for the 5-part format is effectively defensive-only: every redirect URL written into a digest is produced via encodeURIComponent (e.g. navigation.ts:1917, app-browser-entry.ts:699), and encodeURIComponent encodes ; as %3B, so a redirect URL can never contain a literal ;. Not a bug — the join(";") just can't actually be exercised. Worth a brief comment noting that the slice is purely belt-and-suspenders, or simplifying to parts[2] for the encoded-URL case, since the doc comment's mention of handling URLs with embedded segments is slightly misleading.

event.preventDefault() fires for every redirect error that reaches a global error/unhandledrejection listener. That is the intended recovery path for redirect errors that escape all boundaries, and React's onCaughtError/onUncaughtError hooks keep boundary-caught redirects off the window event channel, so there is no double-dispatch in the common case.

One edge worth a thought: this listener is registered once per AppRouterRedirectBridge mount and dispatches via router.push/router.replace. If two genuinely-unhandled redirect errors with different targets land in the same tick (e.g. concurrent rejected promises), both will dispatch inside startTransition and the last one wins — same as a user calling router.replace twice. Non-blocking, just noting the bridge has no per-event dedup; the reset()-driven boundary path is the one that guarantees single-dispatch, and this global path is a best-effort safety net.

The added Math.abs(window.scrollY - y) <= 1 early-exit is a nice improvement over the prior pure 60-frame loop — it stops as soon as the target is reached instead of burning all frames. Note this only short-circuits the vertical axis; if y is unreachable (content settled shorter) the loop still runs the full 60 frames clamping at max scroll. That matches the upstream parity goal, so this is fine as-is — just flagging that the x axis isn't part of the convergence check, which is harmless given vinext only ever passes a real x for horizontal-scroll restores.