When fixing SERVER-54507 we discussed a possible future optimization in preparing to execute $merge. The idea is to check the targetCollectionVersion epoch against matching later on when you are not holding the DB lock, or call

ShardServerProcessInterface::checkRoutingInfoEpochOrThrow()

not under a DB lock right before execution of the query on the leaf nodes of the merge topology.

Why would this be better? 

The short answer:
Because the shard is serving as a router and not as a shard, so this epoch check also doesn't matter theoretically.
The long answer:
Because the current check only makes sure that this MongoD (pretending to be a router) knows at least as much as the router which sent the merge command. However, in the grand scheme of things both can be wrong and agree on the same wrong thing.  It's more correct to have the leaf nodes of the merge topology do the epoch check or to call 

ShardServerProcessInterface::checkRoutingInfoEpochOrThrow()

Which avoids the case where the leaf nodes that do the data reads know about a dropped collection and the mongos doesn't at the time it sends the targetCollectionVersion to the mongod acting as the router.

Note that there could still be a pathological case where the merge topology has 2 leaf nodes and one is reached much earlier than the second, and the first one processes Petabytes of data when the collection is dropped on the second leaf. The only theoretical way to get around this is to probably open cursors on all shards that will participate in the merge plan, but that would be possibly infeasible.