A well designed device knows you are following Leg 1 and where leg 1 and leg 2 intersect has no interest in placing you on Leg 2 because it isn't wasting battery and CPU cycles trying to match the whole route at once but has loaded up around 1km.
As probably the only person here who's written such an algorithm*, this is exactly what it does. Well, with a bit more complexity.
The first time the algorithm runs, it searches the whole route until it finds a point that is below the "on route" threshold (50m). It then continues searching for a better point. If it goes more than 1 km ahead of the best point that it's found without finding a better point, it gives up and declares the best point found is "where you are".
The second time the algorithm runs, it does the same thing but starts the search at the last identified best point on the route. If you are on route, this usually means it will only be searching the 1 km or so ahead. This makes the point strongly inclined to only ever move forward along the route (unless none of the points in that 1 km are within 50m, when it'll loop through the whole route).
If you set off in the wrong direction - for example, there's an out and back on the same road, and it guessed wrongly which you were on - you have to go 50m behind the "best point" before it figures out what's going on.
It doesn't remember the "best point" between reboots, so if you restart you'll get the first part of the track that matches, until the tracks diverge.
And note, I wrote all this not really to help with navigation, but because I wanted to provide a simple number for your distance along the route.
(On modern devices, having the whole route in memory and searching through it, even if it's 100,000 points, is a pretty negligible operation. Garmin 10,000 points limit is like something straight out of 1998)
* Shameless plug:
https://bikegpx.com