Routing augmented with historical data has been their standout feature ever since their first baby steps in route planning, it's pretty much orthogonal to the input method.
Unrelated to the footpath UI: last time I checked that historical data did not exactly lead to superior routing at all, because too many different activity types got bunched together: you don't want to get sent down that road that is only good for running/riding when it is closed to traffic for a major event once a year, which causes enough trackings to light it up like crazy on the heatmap. You don't want to go down that immensely popular gravity MTB trail on your roadbike. The list goes on. I get much better routes from a engines working on a plain OSM+elevation dataset. I don't know wether that is because I treated it before they made great improvements, because they have never really tried our because they tried and failed to make it better. I suspect that it is "never really tried" because I expect the kind of talent Strava attracts to easily ML those problems away if they would/could really put their minds to it and because lack of depth seems to be the universal rule for all Strava features outside the narrowest core of, I don't know, "competitive social".
PS: didn't even mean to refer to the introduction of footpath-style UI in "UI change". Initially I wrote "UI color change", but then decided to dial down a bit on exaggeration. But it kind of makes sense either way.
Oh, and the "footpath UI" certainly is UI, but neither the kind of superficial change that I intended to refer to nor purely a frontend change, it certainly does need considerable algorithm work on the backend.
Personally I find "the footpath UI" very cool on a technical level, but perfectly useless on the level of actual utility for my use cases: as a cyclist I always go either completely without a pre-planned route or with very specific goals in mind (either destination only or with very opinionated tweaking for every detail of the route), never something like "this shadow, that direction, about xyz long". I understand that runners might have more firing needs ("find something nice that connects me through park X, garden Y and gets me back along the waterfront, 90 minutes at peace Z")
Unrelated to the footpath UI: last time I checked that historical data did not exactly lead to superior routing at all, because too many different activity types got bunched together: you don't want to get sent down that road that is only good for running/riding when it is closed to traffic for a major event once a year, which causes enough trackings to light it up like crazy on the heatmap. You don't want to go down that immensely popular gravity MTB trail on your roadbike. The list goes on. I get much better routes from a engines working on a plain OSM+elevation dataset. I don't know wether that is because I treated it before they made great improvements, because they have never really tried our because they tried and failed to make it better. I suspect that it is "never really tried" because I expect the kind of talent Strava attracts to easily ML those problems away if they would/could really put their minds to it and because lack of depth seems to be the universal rule for all Strava features outside the narrowest core of, I don't know, "competitive social".