The multikey variable on indexes serves a dual purpose:

1. First, readers seeing true cannot assume an index contains a record id at most once (thus requiring the reader to dedup documents).
2. Second, writers seeing true may skip updating the catalog.

In the absence of using the storage engine snapshot to determine the multikey state of an index, a single variable is insufficient to satisfy the concurrent reader-writer contract as well as the concurrent writer-writer contract.

This setting of multikey in an onCommit prevents the writer-writer contract from being violated. Writers can only skip setting multikey once a storage engine transaction has successfully committed.

However it allows a reader-writer error. A reader that slices a writer's storage engine commit and its onCommit handlers can see a snapshot with multikey data, but see an in memory value of false.

The alternative of unconditionally setting multikey outside of the onCommit, prior to the storage engine committing leads to a writer-writer problem. A few cases can go wrong. For brevity, we can describe the most egregious case. Suppose the writer that flips multikey in memory rolls back its storage engine transaction. Future writers will never try to correct the multikey value on disk.