Can you batch vertex data and still sort by depth? In order to reduce the amount of draw calls per frame I've decided to use a vertex array object to store vertex data from several different meshes. More precisely, I use the vao to the define the vertex format (attributes) and the buffers which contain the vertex and index data.

Now I could call glDrawElements on the batch's vao once and draw all the stored vertex data directly. But I also see a lot of discussions about sorting your draw data front-to-back for opaque objects (in order to reduce overdraw) and back-to-front for translucent objects (in order to blend 'correctly'). 

I was wondering how you would go about sorting the contents of several vertex batches (vaos) even though a batch most likely contains data for objects at different distances from the camera. 
Say batch A contains objects with depth { 1, 3, 5 } and batch B contains objects with depth { 2, 4 }, how could this be sorted properly so that it can be drawn in the order { 1, 2, 3, 4, 5 } without specifying 5 separate draw calls (with each a different buffer offset).

Were it just the overdraw optimization I would probably just say screw it as it would allow me to draw an entire buffer's contents in one go (instead of having a draw call with a different offset for each object), but then there's still the sorting of translucent objects.

Thanks in advance!
Drawing back-to-front is not optional with blending (unless you use an order-independent blending technique), so getting the visual effect you actually want has to trump performance.

But drawing front-to-back is purely a performance thing. Specifically, it makes it possible for early-Z to save you fragment processing time, as earlier objects are in front of later ones. So it's a GPU performance improvement.

Batching is a performance improvement for the CPU, in that you're spending less CPU time doing state change stuff.

So you need to decide which is more important: CPU performance or GPU performance. With deferred rendering, saving FS computation time also means saving memory bandwidth.

But the general construction of your scene, what you're actually drawing, can help inform which is more important.

Oftentimes what happens is that you render static terrain first, perhaps using your visibility system to order what you render coarsely front-to-back. Then you render your dynamic objects. Because dynamic objects usually require a lot of state changes, you won't necessarily draw all of them in a single batch (though there are techniques you can use to hide even texture changes).

In any case, the point is that there is a tradeoff. And the one you pick depends on exactly what you're rendering. A top-down game like StarCraft or DotA would never bother with front-to-back sorting; you just render the terrain after the characters. A tight-quarters FPS by contrast would probably really need to employ such techniques, particularly for terrain.