I would agree, except that it’ll still be challenging to educate people about the nature of this tag. As I understand it, the intended scope of highway=motorcycleway
is something akin to a cycleway but for motorcycles rather than bicycles. Not exactly a road for motorcycles.
Maybe some unintuitiveness or ambiguity is OK. We already cope with any confusion between service=emergency_access
(such as a fire lane) and service=driveway
access=no
emergency=designated
(the driveway to a hospital emergency ward). We already cope with any confusion between highway=service
bus=designated
(an aisle within a bus station) and highway=busway
(a BRT lane).
But I pity the community members who thanklessly translate our editor presets and documentation. It’s hard enough to align concepts across languages without additionally creating a special OSM jargon to translate from.
For my part, when I translate iD to Vietnamese, I have to contend with the fact that everything in that language is a “road”. A motorway is literally a “high-speed road”, a cycleway is a “bicycle road”, and a footway is a “walking road”. A path is literally a “worn road”, as in a road made by wearing down the ground. The highway=*
key actually makes a lot of sense in this language! But I have no idea how I’ll accurately translate “motorcycleway” for mappers in one of the countries that is supposed to be a beneficiary of highway=motorcycleway
. How do I communicate the difference between a “road” and a “road”?
Yes, I agree that “route” is the usual term in plain English for any defined trajectory that may or may not be guided by something obvious on the ground (e.g., a climbing route). However, it’s a very overloaded word in a technical context. In the case where there is something obvious on the ground, one tends to use the term “route” only for designated routes, which is how we generally use route=*
on relations.
For better or worse, there’s already some precedent for the term “link” to represent virtual ways that link together less abstract ways: footway=link
, waterway=link
, etc. I guess the analogue would be highway=path
path=link
, which would send us right back to the starting point, since we don’t actually want unaware data consumers to conflate them with real paths.
Calling it an area makes a lot of sense. And since routers have so much trouble routing through areas instead of around them, we tend to map the likely trajectories through them. It’s a highway=footway
through a highway=pedestrian
area, but of course it would need to be something else through one of these pathless areas.

The part I don’t understand is: if I’ve walked the path, so now I know what its surface is, its smoothness, its width, etc. then what’s the value in leaving off one of these tags, in deciding not to add it, because it’s equal to the documented default?
Surely it’s better to just add all the information I have about the path?
A few more tags will make it that much harder to fit the planet on a floppy disk. I agree with this perspective when it comes to access tags and other discrete tags, though apparently others don’t. But I can’t imagine having to pause and estimate the width of every path I take. Jotting down all those details, tape measure in hand, would take all the fun out of going on a hike. Maybe using the metric system gives you all better short-term memory? I should try that sometime.