At present, when dropping a sharded collection, the drop command is dispatched sequentially to each shard. This means that each successive drop always has a higher clusterTime than its predecessor, such that the drop events appear in a change stream with a specific ordering.

However, this ordering is due purely to current sharding mechanics and is not reflected in the resume token format. If a sharded collection were to be dropped on two or more shards at the same clusterTime - as might happen if the sharding team decides to parallelize the collection drop operation - then the events on each shard would produce identical resume tokens, since they all have the same UUID and no documentKey. This would lead to exactly the same ordering fiasco as described in SERVER-34554, and for the same reasons.

If and when we decide to update the resume token format to address SERVER-34554, we should make sure to address this potential future problem as well.