A primary node generates a create collection oplog entry where a new collections uuid is stored in the ui field, and stripped from the o field.

Ex:

db.adminCommand({
  applyOps: [
    {
      op: "c",
      ns: "test.$cmd",
      ui: field defined.
      o: {
        create: "myCollection",
        // UUID explicitly removed from 'o' document.
      }
    }
  ]
});

However, a user initiated applyOps isn't bound by the contract the 'uuid' doesn't belong inside the 'o' subObject.

Pre-existing behavior for applyOps: 

•  If o.uuidi is present + ui is none = use o.uuid

  db.adminCommand({
    applyOps: [
      {
        op: "c",
        ns: "test.$cmd",
        // no 'ui' field defined.
        o: {
          create: "myCollection",
          uuid: UUID("ae985829-b672-4309-a10b-1f763ec07de9")
        }
      }
    ]
  });
  // Currently, true
  assert(bsonBinaryEqual(db.getCollection("myCollection").getUUID(),
                         UUID("ae985829-b672-4309-a10b-1f763ec07de9")));

  Where 'cmdObj.addField' replaces o.uuid only if ui exists. Otherwise, CollectionOptions are parsed with o.uuid.

It is unclear whether this behavior is intentional, or a side effect of how the code was written. At the very least, the code should document the expected behavior - especially when both fields are present and conflict.

Note: If the presence of o.uuid should throw, we should assess the risk with existing downstream tools.