Context: Parameter multiplexing systems have become widely used to support an ever-increasing number of features on avatars, and to make room for more than a handful of options once the VRCFT template was added. These systems have depended on the fairly consistent update rate of 10 times a second (0.1s interval) and so have been built with that documented behavior. Recent changes to how parameters are synced have made these systems less consistent, it was stated that these systems were never supported (despite the docs and consistent in-game behavior for years) but efforts are being made to not break these systems. I suggested versioning the Expression Parameters (just like physbones/raycast) so that new features (like bit width, signed/unsigned, etc) would only apply on new uploads, and that expression parameters "1.0" would sync as they have before, in my opinion that's still the best approach (guarantees that existing uploads would remain functional), that was unfortunately shut down "There will not be a compatibility shim, as we are making these changes to guarantee server stability and cost." -@pi . Regardless of expression parameter versioning or not, the multiplexing systems are unlikely to be going anywhere since many modern avatars often use 400-600 bits for their base features (VRCFT aside), and so we'd be encountering the same inconsistent interval issues (be it on all uploads, or only on "1.1" uploads if versioning is accepted as a solution) since the local avatar cannot tell when parameters are sent to remote, as our 0.1s interval no longer holds true, and for the lack of a better timing mechanism. So a parameter update clock is needed, for example ParameterUpdate as a bool, that simply flip/flops it's state once current parameter values are sent to remote users, the interval should be dictated by the "fastest" update a remote user sees (if one user is very close and should see the update in 0.1 seconds and another is very far and only receives an update in 1 sec intervals, it should be based on the closer user's 0.1 interval) as that's been what we've been operating on, though I would not oppose additional options like ParameterUpdateLast for the latest update and ParameterUpdateMedian for when most people would see the updated values. This clock could also be used to drive a local cue for a user for certain features, specially ones that require syncing with remote users, like world drops, by displaying an effect locally when the world drop should be active for nearby/most/all remote users, meaning that moving would not cause it to be misaligned.
