Provided that featureFlagShardingFullDDLSupportTimestampedVersion is enabled, consider the following situation:
1. Configsvr starts fcv upgrade 4.4 -> 5.0. Thus, persists kUpgradingFrom44To50 fcv value.
2. Metadata patchup for phase-1 completes: This means that chunks now have uuid, we have build the uuid_1_* indexes and dropped the ns_1_* indexes for config.chunks.
3. Metadata patchup for phase-2 is in progress. We have (partially or completely) $unset the ns from the chunks.
4. Before transitioning to fcv kVersion50, the configsvr steps down
5. The new configsvr primary steps up, ShardingCatalogManager::initializeConfigDatabaseIfNeeded is called, which will call ShardingCatalogManager::_initConfigIndexes. Because the current fcv value is kUpgradingFrom44To50, it will create the indexes for ns_1_*, but he have already $unset the 'ns' fields from the config.chunks, so it will fail due to DuplicateKey errors.