While reviewing new code from PM-1632, I spot-checked some existing patterns for how the collation is being resolved by mongos. It appears the are multiple cases where the std::unique_ptr<CollatorInterface> is left nullptr when the collation specification is an empty BSONObj() despite the rule being "when the collation is unspecified in the request the collection's default collation is used to satisfy the operation." Without further investigation it is unclear the extent to which mongos would be doing post-processing of results after merging cursor results (e.g. $group followed by $match) where the collator used by mongos is relevant for the correctness of query results.

Moreover, the contract desired by ExpressionContext is impossible for mongos to uphold given that mongos has no knowledge about the default collation for unsharded collections. The sharding catalog only stores the collation specification for sharded collections.

* The ExpressionContext is always set up with the fully-resolved collation. So even though
* SERVER-24433 describes an ambiguity between a null collator, here we can say confidently that
* null must mean simple since we have already handled "absence of a collator" before creating
* the ExpressionContext.

Hopefully we can produce an interface which leverages the C++ type system to enforce the following contract:

1. mongos incorrectly fills in the collator for unsharded collections as simple collation but promises to not ever use it.
2. mongos correctly fills in the collator for sharded collections by consulting the ChunkManager and uses it when responsible for merging + post-processing.