Minimongo cache staleness after publication argument change

This question addresses the observable window in which minimongo retains documents from a previous Meteor publication when a subscription is restarted with modified arguments. The goal is to characterize the conditions under which this staleness persists and whether it scales with network latency or server-side reactive timing. Key uncertainty involves the precise threshold at which the client's data source transitions from cached documents to server-removed messages, and how different Meteor release lines handle cleanup during argument changes.

Specific questions:

• How does the stale-cache window duration scale with round-trip latency in Meteor release lines?
• What triggers minimongo to purge cached documents when a publication's argument set changes mid-subscription?
• Does supplying a version token in publication arguments guarantee immediate cache invalidation, or does it depend on the next server observeChanges cycle?