I think this is a source of some awkwardness. The existing but undocumented street:name key is much less awkward in my opinion and could be paired with street:ref is desired. However, it affirmatively states that the way is associated with a street. In my experience, a sidewalk typically is associated with a street, but it becomes awkward in the relatively fewer cases where a sidewalk is associated with a motorway, driveway, or cycleway. These aren’t obviously “streets” to everyone, but then again, neither are they “highways” to everyone either.
If a highway=footway way is tagged with name, OSRM and Valhalla (and probably others) do announce the name when telling the user to turn onto the way, whether or not it has footway=sidewalk. Whether the router does tell the user to turn onto the way, rather than the street, depends on a number of factors. However, the use of name on sidewalks doesn’t seem to be very popular, possibly because it results in clutter in renderers (most of them) that label any footway with a name. Perhaps one solution would be for renderers to avoid labeling footway=sidewalk ways.
As with a lot of generalization problems, inferring the street name has always sounded daunting to me; I’m glad you gave it a try at least. Similar to routing across areas, I do hold out just enough hope in a future algorithmic solution along the lines of Skeletron that I don’t consider the lack of this derivation to be a dealbreaker for separate sidewalk ways.
One workaround I’ve seen commercially is to simply ignore sidewalk ways, biasing against them, and assuming the user will figure out how to follow the car-centric instructions on foot. But this is only a stopgap in my opinion: it doesn’t handle crossings or interruptions in the pedestrian network very gracefully, and it’s highly susceptible to irrelevant access restrictions and turn restrictions.
I suspect it would be more effective to calculate a route that includes sidewalks and map-match it to the road network (again, biasing against sidewalks), setting each maneuver in the original route as a waypoint. Then you could copy the resulting road names back to the original route’s steps. The advantage to this approach is that OSRM, Valhalla, GraphHopper, and others have already built the necessary components. The server can calculate these associations between streets and their sidewalks on demand rather than globally upfront. That said, anything involving map matching requires some tuning to get right.
The proposed sidepath_of scheme highlights a longstanding gap in our data model, which is that a node or way can only express its relationship to another node or way through a relation that has top-down references to its members. Over the years, we’ve made great use of this capability for things like multipolygons and routes, where the most common use cases require a comprehensive view of all the members. However, in reality, relationships can be more “grassroots” and tenuous.
As a case in point, a destinationsign relation (not to be confused with destination_sign, ugh) seeks to incorporate all the signs that merely mention a city as a destination. One can easily imagine how such a relation might get out of hand. If someone were to set up a destination_sign relation for New York City, it would include as members multiple signs leading to each of some 800 link roads, not to mention a few fingerposts on other continents. A mapper with the misfortune of editing in the immediate vicinity of the New York City node would have to load all these referents as part of a standard API call to get all the relevant data within the viewport.
It’s little wonder, then, that keys like name:etymology:wikidata and destination:ref:wikidata exist to outsource these relationships to Wikidata (relying on a matching wikidata tag on the feature being referred to). Thankfully, Wikidata’s notability guidelines are so flexible that any namesake of a building or any destination of an off-ramp is likely to be eligible for inclusion, and obviously some namesakes will never be eligible for inclusion in OSM. But this solution unfortunately doesn’t scale to the even more mundane relationship between a sidewalk and its associated street.