The durable catalog entry for a collection contains a list of indexes.

The in-memory collection catalog contains CollectionImpl objects for each collection, and the CollectionImpl object contains a BSONCollectionCatalogEntry::MetaData object, which contains a vector of IndexMetaData objects.

The CollectionImpl also contains an IndexCatalog, which contains an IndexCatalogEntry for each index, which in turn contains the offset of this entry in the IndexMetaData object, which is used to check/set multikey options for the collection.

When an index is removed for a collection, it is not actually removed from the Collection's _metadata::indexes - instead, _metadata::indexes is set to an empty object at the offset for the index. When this happens, _metadata::indexes.size() will no longer match the number of indexes in the durable catalog - that is, they get out of sync.

In CollectionImpl::initFromExisting, this is a problem because we initialize _metadata from the durable catalog, but initialize the index catalog from the in-memory index catalog, and so the IndexCatalogEntry objects in the index catalog may have incorrect offsets for the Collection on which initFromExisting was called. I.e. if there were originally indexes [a, b, c] and b was removed, the durable catalog will have indexes [a, c], and the in-memory version might be [a, {}, c]. The in-memory offset for index c will be 2 - but in the Collection on which initFromExisting was called, _metadata.indexes will be [a, c]], so that offset will be out of bounds.

We account for this in CollectionImpl::setIndexIsMultiKey by adjusting one to match the other. We may have to do something similar here.