Lee Carré (2021-11-21 12:04:57+00:00): Once again, I'm commenting about what's sound, rather than argument-from-authority (or popularity).

“… undocumented … documented …?”

If I change the documentation, would you still use the same argument?

You've also cited the counts in TagInfo, before, as justification for why one string over another. So, I don't recognise your self-contradictory ‘undocumented’ gambit, here.

When the arguments are inconsistent, yet the desired outcome is always the same, that strongly suggests presuppositions, rather than starting from first-principles.

“What makes an undocumented colon more "backward-compatible" than a documented underscore?”

The backward compatibility is by using the ad-hoc *_cable in addition to more rigorous keys. Instead of only a more structured replacement.

We've discussed, before, this preoccupation with minimising key-count regardless of all other factors (including accuracy).

The consensus is that underscores (except in some legacy cases) are for separating words of the same part of the key, whereas colons are for separating parts (usually hierarchically).

The connector is still type2, all that's different is if it's only a female socket, or a tethered male plug. That's a sub-property, rather than a different type. Much like the electrical properties are.

Much as we have internet_access:fee instead of internet_access_gratis & internet_access_fee, especially since the answer is (commonly) a binary / boolean one.

Thus, especially since there were, as I recall, only about 1000 instances of the ad-hoc *_cable, meaning that it's still new and not even a de-facto convention yet, it seemed appropriate to offer a different suggestion.

This is how things change & improve. Do you not want OSM to improve (or change)?

Why must the first suggestion, even if flawed, be adhered to? Especially since there are examples of replacing ad-hoc convention with structure (diet:* being a very nice example).

By this line of argument, you would have deleted the first amenity=charging_station since it was the only instance of an undocumented tag. What about when new connector types come along?

This is all the more folly since, where I live, there are many differences, which would warrant at least different values to keys, if not entirely different tagging. Some may be unique to the island. That they're uncommon (elsewhere) isn't a valid argument against them.

For example: addr:city makes no sense, here. Jersey has 0 cities. It has only 1 town. For larger places, I can see how using the word city in a key-name often makes sense. What we do have, are parishes, and several villages. Yet, would you still argue that addr:city should be used instead of addr:parish ?

You seem to make a point of seeking such cases. When it's a genuine mistake by a newbie who doesn't know about a well-established tag which means exactly what he intended, then sure (but how do you determine that without asking?). However, when it's not that case (again, how do you determine that?), then it's (frustrating & tedious) interference. Especially that you presume to undo the work of local mappers, instead of asking for the rationale. That goes against the policy of local communities having authority (compared to outsiders) over how their area is mapped.

OSM is about accurately mapping the real world, not trying to make the world fit into predefined categories. Tagging syntax is to serve that end & purpose, not the inverse.

The world isn't a uniform place. It's messy. I've even encountered parking signage which was ambiguous (see http://www.osm.org/note/2698617 ).

If you want newbies to make fewer mistakes, then it's all the more important that tagging syntax be structured & clear, rather than convoluted. So, I wonder how much of this is a self-reinforced (& self-inflicted) problem.

I'm only going to repeat this so many (a finite number of) times. This might be the last time.

“There is a tag to explicitly state if a type2 charging station has a cable. Why do we need another, new tag?”
That argument works both ways, actually. Especially since *_cable doesn't follow syntactic conventions.

Why would you want an unstructured syntax, instead of an existing structured one?

I could also make an argument about what'd be easier (in terms of keeping code simpler) for data-parsers.