Major OData V2 spec for batch responses (Example 2) shows a response with multiple errors. OData V2 didn't have a continue-on-error preference to obtain this, it was just assumed that a batch could have multiple requests that were able to fail and the client would find out about all the failures.
For V4 we have Prefer (odata.continue-on-error) but it is opt-in, and optional for the server to support.
V2 clients had certainty that a server supporting batches would be able to return a single response with all parts (whether or not an error had occurred).
V4 clients no longer have that certainty, which from a performance perspective (in the presence of errors) is unsatisfactory. If a client sends a lot of GET requests that might return 404, they might only get one 404 response (batch response is truncated at the first error). Then they needs to resubmit the tail end of the batch. Time complexity is proportional to E*N*L, where E is the number of errors in the batch and N is the size of the batch request payload and L is the per-request latency.
We have clearly lost an important performance characteristic (clients having certainty about the cost of a batch of requests some of which can fail).
How can we get it back?
Perhaps we can make continue-on-error mandatory for servers to support if they support batches at all.