Begin of the insertion_N.B. This is "hypothetical bug" - an issue found with AI tooling. It is unclear whether this manifests itself as a user-facing bug currently._

End of the insertion ## Context

Found while adding test coverage in #OP-19666 (custom-element morph policy consolidation) for a code path that had zero prior tests. Pre-existing, not introduced by that work -- confirmed the buggy `replaceWith` call is unchanged on `dev`.

## The bug

`frontend/src/stimulus/controllers/dynamic/work-packages/dialog/preview.controller.ts`, in Begin of the insertion`DialogPreviewController`'sEnd of the insertion Begin of the deletion `DialogPreviewController`'sEnd of the deletion `beforeNodeMorphed` callback (shared by `date-picker/preview.controller.ts` and `progress/preview.controller.ts`):

```js
if (oldNode.tagName?.startsWith('OPCE-')) {
if (schedulingChanged) {
oldNode.replaceWith(newNode);
}
return false;
}
```

`oldNode.replaceWith(newNode)` detaches `oldNode` from the DOM as a native side effect. Begin of the insertionidiomorph'sEnd of the insertion Begin of the deletion idiomorph'sEnd of the deletion `morphChildren` loop (`idiomorph.esm.js`, `morphChildren`) tracks its walk position via `insertionPoint = bestMatch.nextSibling`, evaluated Begin of the insertion_after_End of the insertion Begin of the deletion *after*End of the deletion `morphNode` returns -- but `bestMatch` is the now-detached `oldNode`, so `nextSibling` is `null`. The loop then falls through to Begin of the insertion"insert/remove"End of the insertion Begin of the deletion "insert/remove"End of the deletion tail logic instead of continuing to morph siblings.

**Net effect:** when `schedulingChanged` is true and an `OPCE-*` node is replaced, any DOM sibling that follows it in the same parent is never morphed -- Begin of the insertionit'sEnd of the insertion Begin of the deletion it'sEnd of the deletion left stale.

Verified empirically with a standalone debug spec calling `Idiomorph.morph()` directly: Begin of the insertion

```textEnd of the insertion
Begin of the deletion ```
End of the deletion BEFORE replaceWith, nextSibling: <div data-marker="old">old</div>
AFTER replaceWith, oldNode.nextSibling: null
AFTER replaceWith, oldNode.parentNode: null
FINAL HTML: <opce-test-marker data-marker="new"></opce-test-marker><div data-marker="old">old</div>
```

## Why it went unnoticed

No existing spec mounted a sibling alongside the OPCE node in the Begin of the insertion`schedulingChanged`\-replaceEnd of the insertion Begin of the deletion `schedulingChanged`-replaceEnd of the deletion case, so the gap was invisible until #OP-19666 added coverage for it.

## Possible directions (not decided)

Begin of the insertion* End of the insertion Begin of the deletion -End of the deletion Trigger a full container morph/re-render after the manual `replaceWith`, rather than relying on Begin of the insertionidiomorph&#x27;sEnd of the insertion Begin of the deletion idiomorph'sEnd of the deletion loop position afterward. Begin of the insertion

* End of the insertion Begin of the deletion
-End of the deletion Restructure so the replace happens without leaving Begin of the insertionidiomorph&#x27;sEnd of the insertion Begin of the deletion idiomorph'sEnd of the deletion bookkeeping in an inconsistent state (e.g. let idiomorph handle the replacement itself instead of doing it manually inside the callback). Begin of the insertion


End of the insertion Begin of the deletion

End of the deletion ## Notes

Relates to #OP-19666. The test added there (`date-picker/preview.controller.spec.ts`, Begin of the insertion&quot;replacesEnd of the insertion Begin of the deletion "replacesEnd of the deletion an Begin of the insertionOPCE-\*End of the insertion Begin of the deletion OPCE-*End of the deletion node when scheduling has Begin of the insertionchanged&quot;)End of the insertion Begin of the deletion changed")End of the deletion was narrowed to assert only the Begin of the insertionOPCE-\* node&#x27;sEnd of the insertion Begin of the deletion OPCE-* node'sEnd of the deletion replacement, with a comment pointing to this ticket for the sibling-morph gap.