But the convex shape itself is not sorted - the depth sort order is based on the view direction, which is not the same every frame. Since the buffer contents remains the same and the viewpoint changes every frame, then this can't be a valid argument about the ROP processing order since sometimes you would be in the reverse order. Or am I thinking about that wrong?
The view direction doesn't have to change each frame. Pick any one view direction and render the shape from that direction (and optionally vary any other irrelevant details that might influence race conditions, like processing load, other surrounding operations, phase of the moon, etc). You'll get the same result every time regardless of situational details that would influence race conditions. You always see the same triangles drawn over the top of other triangles, with no pixel/block artefacts from threading bugs within triangles. It will appear as if the GPU has rendered the triangles one at a time in the order specified.
In "foliage rendering in pure" they make use of this property in terrain grass rendering, by having a "tile" of 3D grass planes, with 8 index buffers, which each represent the planes as sorted correctly for 8 different viewing directions. When rendering, they pick the index buffer that has the most correct sorting order for the current view direction, which gives them almost correct back-to-front triangle sorting within each batch of grass.
I'm not disputing that transparent convex shapes render properly regardless of view direction. What I don't agree with is the statement that the order of the primitives has anything to do with it. Unless you do something like what MJP mentioned about duplicating the geometry, then I don't think the order of the primitives makes any difference - front faces will be rendered, and back faces will be culled. Even if the pixels were processed in a random fashion, it wouldn't matter to the output rendering.
For non-convex geometry, I think it is a different story - which is why I think the foliage method that you mentioned has different index buffers for different view directions. This is the main assertion that I am trying to make - that convex geometry will render properly either way, but non-convex geometry does need to have properly sorted primitives.
For certain special cases of meshes you can actually pre-sort them to always render in the correct order regardless of viewing direction. For instance, say you have a transparent sphere that you wanted to be "double-sided" so that you can see both the front and the back of the sphere. A common way to do this is to duplicate all of the faces and flip the winding order so that they show up when back-facing. If you duplicate and append them to the end of the index buffer you get the wrong sorting order, since the front will render before the back. But if you append it to the beginning of the index buffer, the back faces will render first and the front faces will render second giving you the correct blending order.
That is a great way to indicate how this works - and it solidifies the concept in my mind. Thanks for the example and the clarification!