I assume you consider the route relation to be the source of complexity. But many route relations represent non-routes because Waymarked Trails only recognizes route relations. As a result, a router might avoid departing from the “route”, even though it’s just a trail name and there’s no shame in taking a shortcut around part of it. It’s a classic example of why we frown upon tagging for the renderer. There’s already route=fitness_trail to consolidate some named trail infrastructure; should there be a route=trail for the rest? I’m not too keen on further stretching the concept of a “route” for more kinds of non-routes, but at least it’s better than muddling route=bicycle etc. as mappers do today.
Would anyone’s opinion change regarding naming a road based on the numbered routes it carries if we apply this same situation to trails? Many shared use paths and rail trails are still known by their original local names even if they now carry a numbered long-distance cycling route, but we can expect the route numbers to become more prominent than the names over time, especially on the U.S. Bicycle Route System. I grimaced at labels like “State Bike Route 3” when they first appeared on Google Maps many years ago, as overzealous Map Maker contributors eschewed locally well-known trail names. But eventually users will come to expect bike route shields, at which point a spelled-out label conveying the same information wouldn’t seem so weird either.
Do these applications have a strong incentive to do more than the bare minimum of supporting name=* on ways? Regardless of whether these trails in Connecticut should have explicit name=* tags, if enough trails have name=*s nationally or globally, a data consumer might not see the benefit in ingesting relations and all the complication that comes with them.
It reminds me of the tortuous history of way ref=*s and our yearslong hopes of deprecating them in favor of route relations. These days, the situation is looking up, with multiple renderers now supporting route shields based on route relations, but that’s only because the state of the art and user expectations have finally advanced beyond a single number inside a bland badge. It’s gotten to the point where we seldom include some minor kinds of route numbers in way ref=*s anymore, a sort of soft deprecation. Maybe someday, eventually, we’ll drop the other shoe and start removing way ref=*s altogether, but it’ll require a hard decision to leave some data consumers by the wayside.
What would a similar shift look like for trails? If a community-developed renderer such as OpenTrailMap or Organic Maps could draw route shields or something else from route relations, and if a geocoder such as Nominatim could return results for route relations at all, then deemphasizing way name=*s might start to sound more attractive to more mappers.