Change streams have always prevented a user-defined collation from being applied to the filter pushed down into the oplog, primarily so that a case-insensitive collation cannot cause a single-collection stream to return events from multiple similarly-named collections (see SERVER-31443).

This became an issue during PM-1942, since we are now rewriting user filters into the oplog, and the user may have specified a collation for their $match filters. We therefore chose, in SERVER-59426 and SERVER-59840, to abandon any attempt to rewrite the user's query if they have requested a non-simple collation. This behavior ensures that a user collation does not get applied to the oplog query, which could have unintended consequences.

However, in practice the changes in SERVER-56872 should actually make the oplog query collation-agnostic. All predicates on namespace fields now use regexes, which ignore the collation. The remaining predicates all operate on fields that cannot have a string value or fields whose values belong to a limited set of strings that cannot be confused for each other by any collation (e.g., the "op" field).

It may therefore now be safe to allow the oplog query to have an arbitrary collation.