In fact it will depend on the implementations. As you've found, the root cause of the problem is that H1 and H2 use different delimiting techniques for protocol elements. Some implementations need to transcode H2 into an internal representation. In this case, and provided the protocol elements are checked in the intermediate representation, any protocol on the other side will be fine. But if the internal representation is H1-like with poor message delimitation, you could very well end up splitting requests internally and emitting 2 H2 requests on the backend for a single front H2 request for example.

I'd say that the main cause of these issues is the directive language used in the H2 spec almost only saying "this must be done like this" without giving rationale for the rules, meaning that implementations that were unable to implement them exactly the same way were left with no hint about what the trouble was nor how to address it. The new spec in progress and the extraction of the core semantics makes the whole thing a lot cleaner.

In addition, H2 uses much more resources per connection than H1, which encourages to coalesce them between the proxy and the server. But coalescing connections can easily cause some head-of-line blocking if coalesced front streams show different bandwidths. So even end-to-end H2 is not always a panacea.