I would like to thank @_MisterY for putting this forward. I am toying with writing a comprehensive proposal regarding highway=path as I think a global approach should be tried before a piecemeal one, but let’s see.
My general understanding is that the most opposition to doing changes to highway=path is from people who do not frequent trails much (which is what the majority of paths out there are). In the same way, most people opposing pathless seem to be people not ordinarily traversing such terrain. However, this observation might be wrong, it is just based on mentions by various people here and there.
My take would be that the proposal would redefine highway=path not to include pathless.
A secondary path= would be introduced, with several types of paths suitable for various vehicles (my preffered list is two_wheels (everything but cars), shared_use (bikes and pedestrians equally), single_track_mtb and snowmobile (which could also combine with pathless if winter only and not permanentlysigned)).
Then path=trail for hiking trails/mostly single track ways that are mostly for pedestrian used for transport in less developed parts of the world. An ideal bonus would be a specification that highway=footway should not be used for those, unless locally excepted.
Thenpath=unknown, which would be used for newly added paths when the subtype is not known (like highway=road). That would also be used to know if a path has been retagged yet (highway=path with nothing would still include pathless). path=unknown would make it explicit that it is unknown what it is. I think for practical reasons, it could not be eliminated that it can be also pathless, but people would know to beware. However, all QA tools should encourage its replacement by a more specific value and rendering should be discouraged.
path=pathless would not be in the highway namespace at all. It should require sac_scale=. It would imply trail_visibility worse then intermediate. There would be a grey area between paths that are marked but mostly pathless because they are on rocks and truly pathless ways. I think that is fine, there will always be grey areas. I think sac_scale=demanding_alpine_hiking and above (so T5 and T6) should default to pathless with T4 (alpine_hiking) being either, based on notoriety, frequency of use etc. (official trail marking are strong indication for highway=path, but I think they tend to end at T4 or less in most part of the world).
Good guidelines what to include would need to be made. Pathless should have in its definition tha that line of travel is regularly used. It should be made explicit that only somewhat regular routes that are known to multiple people should be tagged - similar requirements to those here: https://wiki.openstreetmap.org/wiki/Tag:route%3Dhiking#Tagging_walking_and_hiking_Route_Networks
Benefits: difficult trails or trails that are very hard to follow would disappear from common maps, highway=path would have a much better meaning, for interested consumers it would be easy to know “beware here”.
As has been said multiple types, OSM frequently depicts things not observable on the ground, like administrative boundaries. There needs to be a mechanism of verifiability, but that can also be shared knowledge (features do not have their name to be written somewhere to be included in OSM,for example, if everyone in an area agrees on a name).
I can imagine that, but “pathless” has the huge benefit on being meaningful on its own. A user can infer from it that there is no path there. From route=foot, I would assume there IS a path. So maybe route=pathless. However, I was under the impression that route= tends to apply to relations, not ways, so this way of thinking does not make much sense to me.
I think you need to include also horrible and bad for potential candidates.
The point is that typically orsometimes the proposed/sensible way to follow is not the shortest distance between the two (for example it might follow a curving valley, or a countour line on a curved sidehill). The router has not way to know how to render it.
As for beaches, riverways get tagged dually so we have a precedent for that. Yes, users should be smart enough to know that a river flows through a lake, but apparently that approach does not work well so the dual tagging was adopted. From my experince, paths are for this reason quite often marked over beaches anyway already, so moving them to pathless would only improve things. Most consumers will not bother with writing something to plot a path through curved beach so it does not lead you through water.
Abel Tasman trail in New Zealand is the same: Way: Abel Tasman Coast Track (Low Tide) (83505534) | OpenStreetMap