ah yes, and i forgot... if the events that are found, while the query still has a standing subscription (ie, the limit was not reached, or the query was not CLOSEed) the client will receive the later-found events from the L2's background sync query... very often this will happen, and this will mean the Layer1 relay-cache is still delivering the data of the big shared event store in the same essential timeline as if the query results were always returned hot, except the order of the revived events won't be necessarily older than the ones that L1 already found...

it works, anyway. subscription model makes it workable, ultimately the concurrent channel-return model makes assumptions about time that don't need to hold for the pub/sub model... the clients don't really understand it, they just get pushed events tied to a filter that has a subscription id, they don't see the work or care about anything else, it is a channel model for the client anyway