Hash format change is backward-compatible. Inserting the X-Vinext-Rsc-State slot into createCacheBustingInput changes the current hash for every request, including old clients that don't send the header (normalizeHeaderValue(null) → "0", so an extra ,0 lands mid-string). This is correctly absorbed by the rolling-upgrade path: computePreviousRscCacheBustingSearchParam / computePreviousLegacyRscCacheBustingSearchParam spread the state slot as [] (not null), so they reproduce the exact pre-PR field layout ([prefetch, segPrefetch, stateTree, nextUrl, interception, mountedSlots]). The pre-existing "0,0,0,0,0,slot:modal:/" assertions in app-rsc-cache-busting.test.ts still pass, confirming the old hash is reproduced byte-for-byte. resolveInvalidRscCacheBustingRequest only adds these previous hashes on navigation render mode, so an in-flight old-client request validates instead of 307-looping across a deploy.

Prefetch ↔ navigation cache-key parity. Both sides fingerprint getBrowserRouterState(): the navigation path via routerStateAtNavStart (app-browser-entry.ts:1569/1609) and prefetch/Link/Form/router.prefetch via applyNavigationRuntimeRscState → getRscStateFingerprint() → createAppRscStateFingerprint(getBrowserRouterState()) (app-browser-entry.ts:2045). Same source, same serializer.

The conditional-vs-unconditional header set is safe. Prefetch paths set the header only if getRscStateFingerprint is registered, while navigation sets it unconditionally. In the App Router these can't diverge: Link/Form prefetch is gated on hasAppNavigationRuntime(), and the runtime function is registered in the same registerNavigationRuntimeFunctions call that exposes navigate, so by the time a prefetch can fire the fingerprint is available.

Serialization is deterministic. createAppRscStateFingerprint uses a fixed-key object literal; layoutIds/slotBindings are ordered arrays and the value is computed once per client and transmitted opaquely (the server never re-serializes it for hashing), so there's no cross-environment key-ordering hazard.

CDN/Vary correctness. VINEXT_RSC_STATE_HEADER is added to VINEXT_RSC_VARY_HEADER and the exported-Vary assertion was updated to match.

Next-Router-State-Tree stays reserved. Using a vinext-namespaced X-Vinext-Rsc-State instead of populating the Next.js header keeps the protocol header read-only, which is the right call.

Importing the header constant into client/navigation-runtime.ts is fine — server/headers.ts is pure constants with no heavy imports, so no server runtime is pulled into the client graph.

Prefetch-time vs nav-time fingerprint drift. Prefetch fingerprints visible state when the Link/Form scrolls into view; navigation fingerprints it at click time. If the visible router state changes in between (slot update, search-param change without navigation), the prefetched payload simply misses the cache and refetches — graceful degradation, and consistent with how mountedSlotsHeader/interceptionContext are already captured at prefetch time. No correctness impact.

E2E positional-index reliance. Both specs assert requests[0]/[1]. The fixtures set prefetch={false}, so no stray prefetch _rsc requests should race ahead of the click-driven ones — this is what makes the positional assertions deterministic (and is a reasonable improvement over upstream's default-prefetch fixture). Worth keeping an eye on for E2E flakiness, but the design is sound.