Follow-up (3) from #3141 / #3145.
deep(store)/snapshot-style reads compose from the raw store target — which the generator's authoritative flight mutates directly — while per-key signal reads answer from committed values, with landings held in transaction stashes (_pendingValue) until their transition commits. While a transaction legitimately holds a landing, the two reader families answer differently about "the committed value": in #3141's reproduction the DOM (per-key) rendered [1,2,3,1111] while the deep observer reported [3,2,1,1111] in the same flush.
#3145 removed the accidental trigger (a stranger transaction capturing the landing), so the ordinary paths agree again. But the seam is structural: any legitimate transition hold over store landings (graph-driven entanglement, A15) reopens it — deep() will see the post-mutation target while per-key reads still serve the pre-hold commit.
Design question: should deep()/snapshot reads compose over the committed view (per-key semantics, i.e. respect _pendingValue holds), or is raw-target reading a documented property of deep() with the split accepted under holds? A17/A22 lean toward reads being consistent per channel; either answer should be ruled and pinned.
Follow-up (3) from #3141 / #3145.
deep(store)/snapshot-style reads compose from the raw store target — which the generator's authoritative flight mutates directly — while per-key signal reads answer from committed values, with landings held in transaction stashes (_pendingValue) until their transition commits. While a transaction legitimately holds a landing, the two reader families answer differently about "the committed value": in #3141's reproduction the DOM (per-key) rendered[1,2,3,1111]while the deep observer reported[3,2,1,1111]in the same flush.#3145 removed the accidental trigger (a stranger transaction capturing the landing), so the ordinary paths agree again. But the seam is structural: any legitimate transition hold over store landings (graph-driven entanglement, A15) reopens it — deep() will see the post-mutation target while per-key reads still serve the pre-hold commit.
Design question: should deep()/snapshot reads compose over the committed view (per-key semantics, i.e. respect
_pendingValueholds), or is raw-target reading a documented property of deep() with the split accepted under holds? A17/A22 lean toward reads being consistent per channel; either answer should be ruled and pinned.