In oplog application, we ignore the NamespaceExists error returned by createCollection if the collection with the same name but different options already exists.

Most options of createCollection don't affect the semantic of operations on secondaries, like the following (capped collection related are omitted here):
1. usePowerOf2Sizes
2. noPadding
3. storageEngine
4. validation related
5. indexOptionDefaults

However, in 3.4, we added two options that affect the behavior of operations on secondaries.
1. collation in SERVER-23849
2. idIndex in SERVER-26514

collation option
The first one can cause the reapplication of insert lead to different data than the first application because a case-insensitive _id index is created later.

createCollection with no collation
insert { _id: "foo" }
insert { _id: "FOO", x: 1 }
update { _id: "foo" }, { $set: { x: 2 } }
dropCollection
createCollection with case-insensitive _id index

Reapplication of the previous sequence of operations will overwrite the document { id: "foo" }.

In the other case, if the _id index changes from case-insensitive to case-sensitive, an expected document will be considered missing. However, the missing or duplicated document in this inconsistent period is fine because the collection must be dropped later.

idIndex option
The second option about idIndex is to set the correct featureCompatibilityVersion. The insertion of decimal will return an error.

createCollection with v: 2, meaning featureCompatibilityVersion: 3.4
insert decimal
dropCollection
createCollection with v:1, meaning featureCompatibilityVersion: 3.2

The reapplication of these sequence will crash the server because of inserting decimal into 3.2 index.

viewOn and pipeline
If the expected collection doesn't exist because we're in an inconsistent state, the application will fail.

The collection life cycle project will fix all these issues. Another solution is to drop the existing collection if createCollection sees an existing one with the same name.