Bug: `FragmentInstance.compareDocumentPosition` alternates between `FOLLOWING` and `IMPLEMENTATION_SPECIFIC` on every other render

[!NOTE]

AI Disclosure: An AI (Claude Fable 5.1) wrote the issue below. I checked it and take responsibility for it.

React version: 19.3.0 (react and react-dom). The relevant validation code
looks unchanged on current main, so I believe it is still affected.

Steps To Reproduce

1. Render a <Fragment ref={fragmentRef}> with at least one DOM child, plus a
   sibling element after the fragment under the same parent.
2. Call fragmentRef.current.compareDocumentPosition(afterSibling) and then
   trigger any state update (re-render).
3. Repeat step 2.

import { Fragment, useRef, useState } from 'react';

function App() {
  const fragmentRef = useRef(null);
  const [results, setResults] = useState([]);
  return (
    <div>
      <button
        onClick={() => {
          const mask = fragmentRef.current.compareDocumentPosition(
            document.getElementById('after'),
          );
          // The state update re-renders, which flips the result of the
          // *next* click.
          setResults((prev) => [...prev, mask]);
        }}
      >
        compareDocumentPosition(afterSibling)
      </button>
      <Fragment ref={fragmentRef}>
        <p>fragment child</p>
      </Fragment>
      <p id="after">sibling after the fragment</p>
      <pre>{results.join(', ')}</pre>
    </div>
  );
}

Link to code example: https://github.com/uhyo/react-193-playground/blob/51307a38a34202644611223a3f73e415b5ae1640/docs/repro-compare-document-position.html

The current behavior

The result alternates with render parity:

4, 32, 4, 32, 4, 32

i.e. DOCUMENT_POSITION_FOLLOWING on even render generations and bare
DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC on odd ones. The
PRECEDING case (a sibling before the fragment) is affected the same way on
odd generations. Queries for nodes inside the fragment (CONTAINED_BY) are
stable.

Reproduced in Chromium with react-dom 19.3.0, in both development and
production builds, with and without StrictMode.

The expected behavior

A stable DOCUMENT_POSITION_FOLLOWING (4) / DOCUMENT_POSITION_PRECEDING (2)
regardless of how many times the tree has re-rendered. Per the
Fragment docs,
DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC is expected for empty
Fragments and Fragments with children rendered through a portal — neither
applies here.

Appendix

Probable cause

The fiber-tree validation added in #34069
(validateDocumentPositionWithFiberTree) returns
DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC when it cannot corroborate the
DOM-derived answer. Its helpers isFiberPrecedingCheck and
isFiberFollowingCheck in
packages/react-reconciler/src/ReactFiberTreeReflection.js compare fibers by
strict identity (child === boundary, child === target), while nearby
checks in the same file accept alternates (e.g.
current === fragmentFiber || current.alternate === fragmentFiber in the
CONTAINED_BY branch — which is presumably why that case is stable).

The traversal walks the current tree from the common ancestor, but target
comes from getClosestInstanceFromNode(otherNode) (the fiber cached on the
DOM node) and boundary from traversing the FragmentInstance's stored
_fragmentFiber — after a commit these can belong to the alternate
generation, so the identity comparisons miss, the search finds nothing,
validation reports failure, and the fallback 32 is returned. The
fiber/alternate pair swaps roles on each commit, which matches the observed
every-other-render alternation exactly.

Related work (not duplicates)

Searched existing issues/PRs mentioning compareDocumentPosition and
IMPLEMENTATION_SPECIFIC; none report this alternating behavior:

• #32722 added compareDocumentPosition to fragment instances; #34069 added
  the fiber-tree validation this report concerns.
• #37142 fixes an adjacent validation bug (CONTAINED_BY accepted DOM that
  was imperatively moved outside the fiber subtree) by switching to
  doesFiberContain, which does handle alternates — the preceding/following
  helpers may want the same treatment.
• #37578/#37579 (compareDocumentPosition(document) TypeError),
  #37162/#37163 (empty fragments / empty portals), and #37606/#37607
  (portaled fragments in ShadowRoot/DocumentFragment) are different symptoms
  in the same API.