The timeseriesBucketingParametersHaveChanged collection option is:

1. Only set on time-series
2. Serialized as top-level fields (not part of the options sub-object)
3. Defaulted to false at bucket collection creation time

Defaulting timeseriesBucketingParametersHaveChanged to false (bullet 3) is problematic because collections are not only created from scratch but may also be created due to data cloning in the following cases:

• Initial synchronization - when cloning a collection as part of adding a new node to a replica set
• Chunk migration - when cloning a collection as part of migrating sharded collection's data
• MovePrimary - when cloning a collection as part of changing its db primary in a sharded cluster
• Resharding (and moveCollection) - when cloning a collection as part of redistributing all its data
• Mongodump/ mongorestore: when restoring a cluster from a backup

This means that in all clusters starting from v7.1 (SERVER-76258), the value of timeseriesBucketingParametersHaveChanged may be incorrect, leading to incorrect query results (reproducible attached - thanks gil.alon@mongodb.com for providing the sequence of inserts to hit the issue).

The short term solution is to always pretend the option is set to true (not changing the actual value on the catalog but always behave as if it was).

SERVER-91195 will take care of designing a long-term solution for avoiding hitting the issue in the future.