Assume we have delete come in with 2 delete ops, one multi:true and one not

On the first iteration of targeting we process 1 write which ends up being targeted to 2 different shards because it is a multi:true delete, this is as expected. We only target the first delete op because of this check, we have writes to 2 different shards so we cannot process other writes in an ordered:true write (which is correct)

The delete to rs1 succeeds and the delete to rs0 fails. We retarget the write which originally goes through the same formation.

This time since the write to rs1 was already successful we skip targeting it, because it was already done, in this check. In the call to targeter.targetDelete above which generates the endpoints we still return endpoints for both shard rs1 and rs0 (which is correct, that code is deterministic based on the query it doesn't care what has already been executed)

This is a problem because of this code block, where if we are in a multi:true write we call setPlacementVersionIgnored on the endpoint which changes it.

Now since we are skipping the write on shard rs1 the batchMap only has 1 entry, so we don't exit from the loop due to this code. This means we now target the second delete. This delete ends up only being against one shard (rs0), so it gets put in with the shardVersion that did not have setPlacementVersionIgnored called on it

This means we now have 2 writes with different shard endpoints in the same write batch. This breaks this assumption in update/delete (which can cause targeted writes to be incorrectly executed with ShardVersion::IGNORED, which can lead to incorrect write results) or can hit an invariant in bulkWrite.