The proposed implementation for this ticket follows:

Startup behavior without --repair

Fail to start up. If some/all collections have UUIDs set, advise to repair. If no collections have UUIDs, advise to first upgrade to 3.4

Startup behavior with --repair

If there are no collections with UUIDs, advise users to first upgrade to 3.4 and fail. This would occur when the featureCompatibilityVersion document is missing for 3.4 users who have not begun upgrading to 3.6 and 3.2 users.

If no admin.system.version collection exists, create one without UUID.

If only some collections have UUIDs, upsert the following document into admin.system.version:

{ featureCompatibilityVersion: "3.4", targetVersion: "3.6" }

This would occur if we were running featureCompatibilityVersion 3.6 but accidentally deleted either the admin.system.version collection or the admin database, or if we were in the middle of a 3.4 to 3.6 schema upgrade and deleted the featureCompatibilityVersion document.

If all collections have UUIDs, including admin.system.version, upsert the following document into admin.system.version:

{ featureCompatibilityVersion: "3.6" }

We interpret the database as being fully upgraded to featureCompatibilityVersion 3.6, and we insert a featureCompatibilityVersion 3.6 document into the admin.system.version collection. This case would only occur if we were running featureCompatibilityVersion 3.6 and the featureCompatibilityVersion document were accidentally removed or corrupted.