I see your point.That would assume that the user started at the start of the route, which isn't always the case.
I could maybe get around that by checking they are near the start when they start the workout. However I would then need to handle the case where they had to deviate around something. A trail that was blocked or closed maybe. That would also confuse a simple implementation.
The main problem with solutions that work most of the time is that I would get justifiable complaints when people use them in the situations when they don't work. If people started 5 miles before the start of the route and the app was showing 1 mile to go when there are actually 6 miles to go then they won't be happy (and it could even be dangerous).
Sorry about that. I will implement it properly sometime. It is top priority when I have finished with watchOS 9 and the Ultra. It was previously joint top with the always on display, but the Ultra seems to have caused navigational improvements to be much more requested recently.
Was not thinking about all the different implications you are describing.
Still think that it’s better to show it wrong for some use cases than not all for everyone. When other infos for distance or time are set in a schedule that could still overwrite the route info. You anyway give already the warning in the metric that this is “an estimate if necessary “ 😉