So, as an example, if I have three services where A talks to B, B talks to C, and I have a custom version of A & C that require testing E2E, we have to spin up B in the middle.
It definitely is a point of confusion for engineers who have to understand what intermediate services are in play when working on a frontend and some distant backend microservice. Fortunately, that intermediate layer tends to just always be the same two services, so folks learn pretty quickly. At scale, especially hyper-scale in a microservices architecture, this becomes untenable, and either automatic dependency discovery OR routing (like you designed) is the path forward.
Needless to say, it's a "niche" issue I think folks don't run into for a while in their setups; however, once you run into it, it's a PIA for those involved.