The generation of geospatial index keys is known to diverge not only across platforms, but also across versions of the MongoDB server itself. In particular:

• SERVER-74983 details how differences in the implementation/compilation of trigonometric functions can result in different geospatial index keys across platforms. As such, if a mongodb deployment is modified to change platforms (for instance, going from x86 to ARM), running the 'validate' command may report additional index keys.
• SERVER-75392 changed the server to always use 'round half to even' rounding behavior across platforms (previously, non-x86 platforms would use 'round half up' rounding behavior). As such, if a MongoDB deployment on a non-x86 platform upgrades from a version with 'round half up' behavior to a version with 'round half to even' behavior, this can also manifest in the validate command reporting additional index keys.

With both of these scenarios, the issue can be resolved by simply rebuilding the affected indexes (this will have the effect of getting rid of the index keys generated on the previous platform or older version of MongoDB). However, at the time of writing, these cases are treated by the validate command as instances of index corruption. Given that these are known issues that can be detected and remediated by way of rebuilding affected indexes, this ticket proposes modifying the validate command to:

• Detect both of the above scenarios

• If either of these scenarios are detected, emit a special message that's softer than 'index key corruption' to the user along with a blurb about rebuilding the affected indexes.

Note that SERVER-77240 describes one such algorithm for detecting sin/cos divergence (alternative algorithms would be fine also). 

For detecting divergence due to a change in rounding behavior, this is comparatively straightforward: you simply need to detect that either of these values computed when converting a lat, lng coordinate to an S2Point, then converting that S2Point to an S2CellId (which is what we use for an index key) results in a half part that is even (that is,  a double of the form x.5, where x is even). Such a number would account for a difference in rounding behavior: on a version with 'round half up' behavior, this would round up to an odd number), while on a version with 'round half to even' behavior, this would round down to an even number)