I guess the context for this change was https://wikis.world/@samwilson/111084626354658237, which incidentally sparked some discussion in OSMUS Slack: https://osmus.slack.com/archives/C2VJAJCS0/p1695020657752419 .

An individual street isn’t quite the same thing as a route (in the plain English sense of the word). But type=route isn’t just for routes: these days, it’s also used for a variety of routable features, including type=route route=railway for railways, which are analogous to these streets. route=railway causes endless confusion, but it’s very entrenched at this point. At least the previous tagging of type=route route=street kept renderers from getting confused and treating them as highway routes, which require route=road.

The current tagging is technically valid, since type=street also tries to represent the street geometry using the “street” role. This is similar to how type=waterway can include tangentially related members like side streams and springs, but the “main_stream” role is reserved for the main geometry.

That said, I’m not a fan of type=street as documented: it’s basically an attempt to reimplement a geocoder under the false assumption that the technology for data compression or spatial querying hasn’t been invented yet. Taken to its logical conclusion, literally every feature in Fremantle would be part of a street relation.

Another option would be type=multilinestring, which avoids overloading the term “route” while also avoiding the ill-conceived street relation proposal.