Theoretical question about splat sorting in the rasterizer

I'm implementing a custom splat renderer in OpenGL, intended to replicate the pixel colors generated by your training rasterizer, but for different image geometries. Your CUDA and C implementations serve as guides but not code sources. Your rasterizer processes a splat fragment per image tile, sorting them on a key that combines tile index and splat depth. I notice that the depth part is the same for all fragments of a given splat, and I wonder why you did not elect to adjust it according to the 3D shape of the splat? It seems to me that could help ensure more nearly true near-to-far compositing for elongated splats. Since splats occupy volumes, the theoretically ideal way to composite them would be ray tracing, considering all intersected splats in parallel. I understand why that would be prohibitively slow, but I wonder if your algorithm could be tweaked to better approximate it.