q: Can you explain the change of this check?

So, the first block of this condition was updating the span name depending on the context of a lazy-route. That was the reason for the faulty transaction name updates (as the previous navigation transaction's name / route was leaking into the current one).

Turns out it's unnecessary (and also regressed the bug we were trying to fix).

Removing this whole handleExistingNavigationSpan logic (with its lazy-route context checks) fixed the issue, without breaking anything else. We still need to check if we are already inside a navigation span, for the instrumentation cross-usage to prevent nesting / duplication.