Thank you @doug_walker, for taking time to put these points in writing. I’m sorry we have had to go back yet again to go through all this, especially this late in the revision process and because it’s been discussed before.
I did review the conversations from around the 2014 v2 publication timeframe re: this issue and came to the same conclusions as your bullet points.
I agree with #5 that as of right now the functionality is there to satisfy both parties, it’s hard to please everyone, and there’s no benefit to changing names (in fact it could be detrimental to adoption as it will break existing implementations). Other than for “clarity” there’s no reason to re-segment into separate nodes or otherwise rename the operator. Just keep as-is and make even clearer the functionality is already built in for both requirements - scale and clamp.
I am glad it was brought up so that nothing is overlooked but I think we’re still doing the “best” thing here in terms of servicing the need to offer a “convenience scale/offset” and also a “clamp”, as well as not unnecessarily changing the existing spec just for the sake of change. If we were building from the ground up, yes, we could consider restructuring, but it seems a step too far.
I am proceeding on to finishing the other sections. As of now, nothing has changed in terms of functionality of the
<Range> node from v2 to this version of the spec. We had already reached compromise previously and unless there is some yet-unheard-extremely-compelling reason to change, I am in favor of leaving as-is.