See SERVER-83421

From George

today, when we run getClusterParameter on any mongod, the value can be stale or 'ahead' of an update (i.e. roll-backable). When we run it on mongos, the value can only be stale of what is majority-commmitted on every shard + the CSRS, and any change it observes can't be rolled-back

i'm wondering if the second semantic is important to preserve from the automation persepctive. I think the answer might be no because if we consider setting a cluster parameter from A to B and back to A, it's possible for the router to not see B entirely, and when get returns A, there's no way of knowing if it's the first or second