not sure if you can really just change the name, since, as you already mentioned, it’s const. but you can totally just define any behaviour in the lambda that draws the value to the screen as string in the daw. say you have an lfo’s rate parameter and a switch for free/tempo sync (i suppose the most prominent example for this problem?), you’d just put a reference to the switch’s parameter into the string lambda of the rate-parameter and say if it’s value > .5 it will draw the temposync-related values, else the free-running ones.
edit: however, considering that you are open to question your design-decision: while testing different delays and other stuff with such parameters, i did find that most plugins implement it like that. so i also decided to implement it like that in my current project and did so successfully. but after a while i realized that it might not have been worth the hassle. the idea was that if the rate-parameter can be free or sync, people would only need one automation lane to switch between free and sync dynamically. the alternative is that there are always individual free- and sync-rate parameters and only one of them is visible. but i realized that 1. no one ever automates the free/sync switch anyway and 2. if anyone really automated the free/sync switch they’d probably want to immediatly change the new rate-value that results from that anyway, so it’s not bad that it requires a 3rd automation lane to do so. that’s why i now think maybe not only code-readability but even user workflow might profit from not going the sophisticated route.