Starting from v6.0, each range deletion document has a numOrphanDocs field that tells the approximate number of orphaned documents falling into a range. That counter can be incorrect in several contexts: in case of direct writes, while a range deletion is running (because the count goes down after deleting a batch) or during a migration (because the counter goes up after inserting* a batch and may not be updated in case of errors while cloning).

That's a best effort counter that most of the times is correct and is used to approximately tell the balancer how much data for a given collection are orphaned. Worst case scenario when the count is wrong: some more/less data are moved around, not a big deal.

This comment is incomplete and emitting an error here and here for a totally manageable scenario is too much.

SERVER-75299 already reduced the severity of some log lines in the file, we should do that also for the two log lines linked above.