The upgrade procedure creates range deletion task documents in the following way: for each local collection, refresh the routing table and - if sharded - create range deletion task documents for all non-owned ranges.
This procedure does not take into account that no range deletion must happen if the local collection uuid is not matching with the uuid tracked by the config server. This may happen, for example, when a shard holds a stale incarnation of a collection due to
- for each database
- for each collection (found in the LOCAL catalog)
The problem lies in how a range deletion task document is created: the uuid from the local catalog is persisted rather than the one known by the config server.