The "multikeyPaths" field in the index metadata is used to indicate that an index supports path-level multikey tracking. A 3.2 mongod will not maintain the metadata for an index created on 3.4 after downgrading to 3.2. This can lead to situations where the structure of the documents inserted into the indexed collection changes while running on 3.2, and then is inconsistent with the "multikeyPaths" field after upgrading to 3.4 for a second time:

1. Create index {a: 1, b: 1} on 3.4.
2. Insert {a: 5, b: [1, 2, 3]} (the set of multikey paths is ["b"])
3. Downgrade to 3.2.
4. Insert {a: [-10, 20], b: -1} (the set of multikey paths still says ["b"], but is really ["a", "b"]).
5. Upgrade to 3.4.
6. Query for {a: {$gt: 0, $lte: 10}} uses bounds (0, 10] on "a" and fails to return the document inserted in #4.

This change makes it so that on downgrade to 3.2.7, the "multikeyPaths" field is removed from the index metadata on startup. A subsequent upgrade to 3.4 would cause the index to be viewed as not supporting path-level multikey tracking, and would thus fall back to the assumption that every path referenced by the index could be an array value containing multiple elements for at least one document in the collection (i.e. the current behavior in 3.2 and earlier). A user must downgrade to a version no earlier than 3.2.7 from 3.4.