Many reactive systems drain a queue and let handlers enqueue more updates into the same drain, processed right there. But an update that only appears because the batch is running is never new input — it's a consequence, and consequences are derivations. There is no such thing as new source truth in the middle of a batch.

A reactive graph must run parents before children. The real question is when you compute that order. Systems with dynamic dependencies rediscover it on every write. If dependencies are fixed up front, the order is a property of the graph — computed once, then free forever.

A keyed emitter dedups its per-flush batch. The default tool is a Set. A boolean flag on the carrier plus a plain array does the same job ~4× cheaper, paid for with a hand-maintained invariant.

A task queue that lets callers cancel a queued task usually hands back a disposer closure — one allocation on every enqueue. When enqueue is on the hot path, storing the function and cancelling by reference avoids the tax entirely.

If A feeds both B and C, and D reads B and C, then changing A should recompute D exactly once with consistent inputs. The naive wiring recomputes D twice and lets it see one fresh and one stale parent in between — a glitch.

A keyed pub/sub normally keeps a Map<key, handlers>. But the code that triggers a notification already holds the object that changed — so hashing the key again to find its subscribers is wasted work.

index.getEntitiesByKey(key) returns (TEntity | undefined)[], aligned 1:1 with getPksByKey(key). The undefineds are the contract, not a bug.

Updating an entity can either build a fresh merged object or mutate the one already in the store. Each choice serves a different reader, so OIMDB ships both and picks per collection.

For an ordered per-key list, OIMDB doesn't hand you a new array to diff. It emits a stream of commands — insert, remove, move, set, reset — each addressed by position, so an imperative renderer can replay them onto a DOM list with no diff.

Flushing a task queue usually means snapshotting it first, so tasks enqueued during the drain don't corrupt the walk. That snapshot is an allocation on the hottest path. A double buffer avoids it.