When voting turns into “a comments section” many times that is more indicative of the responses to the RFC input not being actually addressed:
“The Rationale is not negotiable.” x2 - the submitter of this proposal straight up said that they were not flexible to user feedback during the RFC process.
1- Suggesting that highway=path + an add on tag was sufficient
2- A RFC specifying that the tagging is non-intuitive where the commenter lists three different definitions for what constitutes a ‘scramble’ that don’t seem to align
“The proposal cannot and shall not deprecate that.” - thus admitting that highway=path is prefer but insists a replacement is still necessary
“only map scrambles where on location signs of actual use by humans” - I’ve done a lot of mountain hiking, even blowing my knee after a summit, and while mountain hiking/climbing books refer to scrambles I’ve never seen one with a sign as it’s simply one of those “I know a ___ when I see a ___” things
“I myself cannot imagine scrambles in other domains as hiking, but others may.” - A single query for “scramble” in TagInfo will pull back 100+ tags that already exist for crossing:scramble (i.e. the “pedestrian scramble” - where all cars get red lights and pedestrians can walk all directions including diagonally. Far more applicable to OSM and only one ranking behind hike scrambling in Google search rankings making them on par with one another and the call for distinguishment between them to be reasonable.
Under “Subjective” the proposer responded, “Additional pictures have been added to exemplify, what use of hands is about.” The issue is that the pictures he pulled happen to be the same from sac_scale=demanding_mountain_hiking AND sac_scale=alpine_hiking BOTH meaning the way they addressed the subjectivity issue of ‘scramble’ is by pulling pictures that span what is already less subjectively defined by the existing sac_scale, which I might point out already has 697,571 tags in OSM use already and is far better suited to the task at hand.
The proposer stated as a resolution, “I hope, that resorting to values in the UIAA scale, as has been in the text from the beginning, will do.” - Then UIAA exists as a tag and UIAA=1 would be the equivalent to a “scramble” although I still think sac_scale does a much better job at deliniation but I see no reason both existing tags with thousands or tens of thousands of uses each can’t be used and don’t already fulfill the need.
“The proposal text puts now even more emphasis on the similarity with highway=steps” that a response to " Existing tags like sac_scale=demanding_mountain_hiking can be used" because highway=steps are clearly definable and have clearly defined starts and stop and clearer still impact on their use by bicycles and the disabled. While ‘scramble’ has none of these distinguishing factors simply pointing to something else doesn’t address the original comment which is that sac_scale not only can be used but already is being used to describe this exact “thing” and in more clearly delineated detail and with a scale and not a binary yes/no flag
“When this goes to vote, I would not be surprised, if the ‘too late’ argument or the ‘we can do that with attributes on paths’ argument may prevent approval, so maybe voters should be asked to write that in the vote, to ease counting of reasons.” - I realize the argument being made prior is that OSM-Carto makes some poor decisions based on highway=path but that isn’t a problem with highway=path that is a problem with OSM-Carto. This goes to “don’t map to the render” as OSM best/good-practice. This doesn’t mean that it’s too late but it also doesn’t disqualify “we can do that with attributes on paths” as an argument as a scramble is more or less a path especially ones that are well trailblazed. In fact, the insistence on sticking with highway=path is largely in line with the one feature, one tag ideology, as well as these, are paths first, hiking/climbing paths second, and at best a scramble third if the first two don’t do the job, which I feel they do.
Bottomline, is if a proposer listens to RFC feedback and actually changes their proposal to address the concerns of those taking the time to comment then those same comments should not need to be repeated in the voting process. I should never hope to see, “The Rationale is not negotiable.” spoken ever as an RFC response and highlight the problem, not as one with the voting or the RFC process but lays those issues at the feet of the proposer who by their own admission in the RFC process expected and discounted the responses they know would likely come in advance.