Can you explain what the reasoning is behind this change, and show an example of how this helps? I don't understand what HSV has to do with transparency.

Sure. After analysing the rendered results of the BSDF, i realized that the outcome is mostly controlled by the value and the saturation of the incoming color in HSV space.

  Alpha behavior in HSV space

    0.0 ^                ~0.75 ( this is arbitrary, but looks ok)
        |
        |
    val |
        |   
        |
    1.0 +--------------> 1.0
              sat
	
  Color behavior in HSV space
  
  black ^                colored
        |
        |
    val |
        |
        |
  black +--------------> black
              sat

The result of the BSDF in cyles seem to roughly follow these rules:

• the hue of the result always stays the same and is always fully saturated (changed in Diff ID 6000)
• the color of the result fades to black with both, decreasing value and saturation of the incoming color. The saturation influence seems to be linear, but the value seems to follow some kind of curve (smaller values make the result black faster). My first guess here was a gamma correction of 2.2, which looked ok. Arbitrary choice here.
• the alpha of the result is always opaque when the incoming hsv value is zero, but fades between fully transparent and mostly opaque with the incoming hsv saturation. I chose a value of 0.75 for "mostly opaque", which looked ok. This is obviously arbitrary too.

You can try it out by opening

This seems all a bit arbitrary to me actually and i'm not even sure it's the biggest problem of transparency in Blender. The unsorted nature of faces in Blender makes transparency work really bad in the viewport.

There was recently paper published, which is probably what we should look into.

After thinking about this for a while, I don't think we should actually be doing this. The idea here seems to be to use emission as an approximation to colored transparency, which OpenGL (and Blender Internal and most image file formats for that matter) do not support.

This approximation works ok with particular light and a particular color of the background or objects behind the transparent object, but if those change then the assumptions break down. For example if you make a dark scene, you'll have bright transparent objects sticking out.

I'd just accept the limitation and do something like this:

void node_bsdf_transparent(vec4 color, out vec4 result)
{
    /* no native colored transparency support in OpenGL, so average */
    result.r = 0;
    result.g = 0;
    result.b = 0;
    result.a = 1 - (color.r + color.g + color.b)/3.0;
}