The classic engine performs an optimization which avoids introducing a shard filter stage if the query contains an equality predicate on the shard key. This has the potential to lead to incorrect query results in the following case:

1. A query with an equality on the shard key causes the planner to omit the shard filter stage.
2. The plan begins to run. A yield occurs.
3. During the yield, a chunk migration occurs and the range deleter removes the chunk which was orphaned. This can occur because the shard filter stage is the object which owns the RangePreserver - in this case, there is no RangePreserver.
4. The scan is restored which reacquires the collection.
5. When the scan continues, the deleted chunks will be gone.

See attached file for more specific repro.

The problem is that the assumptions we made around the orphans of a shard during optimization might not stay the same across yield/restores. The optimization which avoids unnecessary shard filtering is good, but currently incorrect because we conflate the concept of shard filtering and range preservation.