Sharded DDLs typically commit first on the shards and last on the configsvr (with the shards holding the critical section until the commit on the configsvr has completed). This guarentees the property that the new collection 'timestamp' is a cluster time inclusive of the whole operation, after which it is safe to read from the collection.

The resharding commit protocol does not uphold this property – first it commits on the configsvr and later it commits on the shards. While it is true that the critical section is held throughout this sequence, the new collection 'timestamp' is earlier than the local catalog collection rename done on the shards as part of their commit.