Prior to 4.4, the _id of each document in config.chunks is the concatenation of its namespace and min bound. It turns out that the string representation of UUID was changed from "BinData(...)" in 3.4 to "UUID(...)" in 3.6. This has led to a couple of backward compatibility issues with the moveChunk, splitChunk, mergeChunk commands for chunks created in 3.4 for collections with UUID shard key. See example 4.0 test here and multiversion test here. 

1. The "o2" query in the update oplog entries for all chunk commands is incorrect as it cannot match the target chunks (e.g. the query is { _id: foo.bar-34-x_UUID("fa431a05-70ec-41f3-84f7-b82fc61544d5")} but the target chunk has { _id: foo.bar-34-x_BinData(4, FA431A0570EC41F384F7B82FC61544D5)}). Due to an issue related to alwaysUpsert described in SERVER-47744, the chunks commands always end up failing with DuplicateKey error (if in 3.6, see explanation below).
2. In 4.0 and 4.2, the moveChunk and splitChunk commands also use _id to look up the chunk to migrate and split. Since these lookups occur before the applyOps, these two commands always fail with IncompatibleShardingMetadata error.

To solve 1, we should do a simpler version of SERVER-42106. where we store _id that was loaded from the config database in ChunkType and use it for oplog entry query. If _id is not present (because the ChunkType object was constructed through other ways), we can just fall back to using genID. To solve 2, we should change the query in _findChunkOnConfig to include just the namespace and minKey just like in 4.4. A multiversion test should be added to test that these chunk operations work for the chunks described above.