The order does matter, its not a bug. In an OpenGL like drawing pipeline, transparent objects must be drawn back to front. This is because the depth buffer cannot possibly deal with transparency as a concept. A pixel belonging to an object is drawn only when it’s closer to the camera than whatever was drawn there before. If whatever was drawn before was closer, the new pixel is considered to be occluded and is not drawn.
In other words, you cannot draw stuff behind other stuff, only in front of other stuff. This is why Rhino, when it must draw transparent objects, always sorts all shapes back to front prior to drawing them. This can be done because all shapes exist in the same document and thus can be sorted as a single list. However the shapes that grasshopper draws are all stored in different lists (one per parameter). This is why I don’t even bother trying to sort the individual lists, it would at best solve only a very small part of the problem.
One possible improvement is to first draw all opaque objects, and only then draw all transparent objects. It will limit the erroneous occlusion to between transparent objects only. This is something that may be added to grasshopper 2.0