Users can initiate a change stream with a $match, and then resume it with a different one. 

Even if conceptually, this kind of breaks the guarantees of changestream (it won't be possible to consume again the same stream and have the same events), users are still using it and we can't forbid it.

While it doesn't break when the $match is less filtering, in the opposite, having a more restrictive $match may filter the event identified by the resume token and lead to errors like SERVER-71565 and potentially HELP-58098 (cannot resume stream; the resume token was not found).
 

To handle this, we could calculate a checksum of the $match (hash), and add it at the end of the resume token. When resuming from a token, we could check that the $match checksum is the same and log a warning otherwise. The new checksum would then replace the old one in the next resume token.

This would provide a warning to the users without breaking the "feature" or flooding them, and provide us better logs to identify this change in future HELP tickets.