The timeseriesBucketingParametersHaveChanged parameter is stripped whenever we downgrade to 7.0, here.

However, on a sharded cluster, it is possible for us to allow this to persist due to a movePrimary + FCV downgrade race. For example, consider a two shard cluster where the timeseriesBucketingParametersHaveChanged has been set on a timeseries collection that lives on Shard A.
1. Begin downgrade from 8.0 to 7.0: the config server tells both shards to start downgrading.
2. Both shards reach and persist "downgrading to 7.0" transitioning FCV state.
3. Both shards (in parallel) start cleaning up internal server data.
4. Shard B finishes cleaning up internal server data, which involves stripping the timeseriesBucketingParametersHaveChanged metadata field. However, since the timeseries collection doesn't live on Shard B, nothing happens.
5. movePrimary begins and copies the timeseries collection over to Shard B before Shard A has stripped the field. Therefore the field is copied over. movePrimary completes.
6. Shard A cleans up the data on itself, however, as the collection has already been migrated to Shard B there is nothing to do.
7. The FCV transition eventually completes, but the field still exists on Shard B though it shouldn't.

Unfortunately I couldn't repro the bug with the above steps because of another potential bug SERVER-87926, which clears the field unconditionally on a movePrimary (even when no FCV stuff is involved).