There are several places in the code base that call into IndexBuildsCoordinator's static createIndexesOnEmptyCollection function to create an index, as opposed to going through the IndexBuildsCoordinator itself. To prepare the index specs for creation, these callers use IndexCatalog::removeExistingIndexes. However, these index specs result in out-of-order fields compared to index builds that use the IndexBuildsCoordinator, because the IndexCatalog::prepareSpecForCreate function, which is called via MultiIndexBlock, re-orders the fields. Even though IndexCatalog::removeExistingIndexes does call IndexCatalog::prepareSpecForCreate, the spec objects returned by prepareSpecForCreate are unused.

The implication of this bug is the oplog entries for different index builds will have a different ordering of subfields inside the "o" field.

Using the return result of prepareSpecForCreate in the return result of removeExistingIndexes should address the ordering inconsistency.