The orphan deleter script added in SERVER-115996 performs COLLSCAN when deleting orphan documents from collections with single-field hashed shard keys. This makes the script impractically slow on large collections.
In deleteMany, single-field hashed shard keys take a code path that builds a deleteMany query using $expr with $toHashedIndexKey. We cannot use indexes for $expr queries involving computed expressions, so the query planner falls back to a COLLSCAN regardless of whether a hashed index exists. Each range deletion task triggers a full collection scan, and since the script runs ranges in parallel, multiple concurrent COLLSCANs hit the same collection.
Compound hashed shard keys are not affected as they already use a separate code path that leverages .min().max() hint for IXSCAN.

The fix probably is to route all hashed shard keys (single or compound) through the same path, eliminating the $expr/$toHashedIndexKey query entirely.