It has always been the responsibility of data consumers to use the data correctly, not for data producers to pander for their weaknesses; that’s why the don’t tag for the renderer rule exists. Trying to avoid this by saying a data producer must do the development work for the consumer (and without even knowing whether they have the skill to do that), is, in my view inappropriate.
In any case, in many of the cases, the polygon is convex and has no cutouts, in which case the routing only becomes difficult if two polygons share edges.
As I’ve demonstrated, some of the fictitious paths that people add are actually worse than the result of simply using the shortest path over a convex polygon, as the fictitious paths have been added by an algorithm that doesn’t take account of everything mapped and certainly doesn’t take account of the real world, but also doesn’t produce the route that a real person would use, when there are no obstructions.
The reason that I added a note, and didn’t just remove the fictitious paths is that I’d likely end up in an edit war, and I can do without the stress and time wasting of that. Edit wars are an, unfortunate, side effect of an environment with only weak central control. The reason I don’t re-arrange the paths into ones that are physically possible to use, is that that would be acknowledging that tagging for the renderer was appropriate.
Although the best solution is for routers to use the real world information to choose a best route, if one has to compromise, fictitious paths should not be highway=footway, but should be something that clearly indicates they are not real. Although you could argue that it would be up to the renderer, if you used something like routing_hint=yes, there has to be some sort of principle that common cases should be recognizable based on just a few tags, so a renderer seeing highway=footway should not have to look further to realise it doensn’t really exist. As such, I’d say highway=routing_hint, is better than an additional flag, if they must be included.
Of course any such hint is unverifiable, as it represents a personal judgement.
I also note that one contributor to this thread has pointed to a tool that already allows such hints to be be generated for routers. I haven’t looked closely at it, so I don’t know how it works, but, in principle, it could presumably create a database that could be substituted for planet.osm, and allow routers to work without modification.