This lack of "global optimization" I think is something that should be solved by a new protocol stack. (If it could be done without replacing the whole stack i'd be in favor of it, but I have no idea how)
Say you have a backend tcp http REST app that takes requests to modify a widget. To receive the request, the payload will pass over a series of networks and protocols, all with potentially different restrictions and modifications, until it gets to a load balancer, and then maybe a service mesh router, to a network service listening on the node of some container orchestrator, and finally read by the backend app.
All of the layers will have been replaced numerous times, and possibly the actual data payload modified. But the only thing your backend app knows is the final state. And then, somewhere along the way, there is an error. It could have happened anywhere along the chain, for who knows why. But you and the app server won't know when or where or why the error happened because none of the information about the changing layers (or network operations along the way) is carried along.
If the entire stack were not actually a stack, but instead a kind of commit log of transactions and instructions, we could see every single step in a transaction (ideally verified by cryptographic checksum). This would make it faster to diagnose problems and allow automation to work around known issues - in addition to making it harder for attackers to mess with traffic. In the simplest examples it would look like a stack, but for more complex paths it would look like a log. We could also potentially use this method to do away with service meshes.