Similar to SERVER-87191, Timeseries updates/deletes without shard key using the single shard optimization checks getNShardsOwningChunks, which does not respect atClusterTime chosen for a transaction started with snapshot read concern. This can lead to inconsistent targeting similar to the linked ticket.

The scenario to investigate is:

1. Start transaction with readConcern: snapshot
2. Perform update to some coll so that T1 is now the current timestamp
3. moveChunk for coll2 so that all chunks are on one shard
4. Perform an update on coll2 in the same transaction

In using getNShardsOwningChunks, we may start the transaction with knowledge that coll2 has chunks on multiple shards, but by the time we run step 4 getNShardsOwningChunks will register that there is only 1 shard with chunks for coll2. I'm not sure if this will definitively lead to the same issue in SERVER-87191, but the inconsistent routing throughout a transaction should be addressed.