Early on the decision was made that all Guids in a collection MUST be represented the same way. The rationale was that mixing Guid representations in the same collection would lead to confusion.

This was enforced by the readers/writers and serializers which looked at the GuidRepresentation value of the reader/writer settings (which came from the collection settings). The readers/writers/serializers either do automatic conversions or throw exceptions as necessary to enforce the constraint that all Guids in a collection MUST be represented the same way.

This constraint, and the automatic conversions in particular, have become problematic now that the server has started using UUIDs (e.g. ListCollections results and session Ids among others).

The server only uses BSON binary subtype 4 for UUIDs, so any automatic conversions to subtype 3 result in server errors.

At the very least we need to support a mix of subtype 3 and 4 in the same document.

In the longer term we should probably remove all conversions/checks from the readers/writers and leave all decisions about Guid representation up to the serializers.

Changing how we handle Guid serialization could have subtle backward compatibility issues.