Theoretical sequence:

1. New migration started on destination for chunk with range A, it waits for existing range deleter task to complete. This is based on query on the config.rangeDeletions collection.
2. Range deleter service finished deleting range A, and tries to delete all the range deletion task documents that match the range. It deleted one doc and yielded.
3. Migration destination thread saw that doc no longer exists, so proceeded to queue it's own range deleter task for range A.
4. Range deleter service thread comes back from yield and continues iterating and saw the newly added task by migration destination thread and deletes it.

If the migration ends up aborting, the donor will update the range deleter task to remove the pending status, but since the range deleter task document no longer exists it will not perform any cleanup, and the documents in the destination will end up become orphans.