Sorry, this is a step back towards Gimp 0.54 where you had no embedded alpha channel in the images and compositing of two images (that had to have the same size) was done via a third grayscale image (that also had to have the same size).
I am not suggesting that alpha is gotten rid of entirly in all cases. Just that in this specific case, where you want the full opacity to be controlled by a layer mask, you should get rid of alpha in the area where you want the layer mask to control your opacity. This is specifically because of the overloaded nature of alpha here. Alpha is being used as transparecy but (correctly) is mathematiclly treated as the coverage.
When being forced to use the layer mask for all images where I might decide to increase the opacity later drawing some random strokes on the layer becomes a non-trivial task, because I have to care that these strokes are drawn exactly the same in the layer itself *and* in the layer mask.
This is why I suggested earlier the seperation between transparency and coverage. Any drawing operation would have to consider whether it is adding transparency or coverage or both at every pixel (a pixel could be partially covered by a transparent effect). This would mean that instead of an alpha channel and a layer mask, we should have a coverage channel and a transparency channel. (giving way to RGBCT colorspaces). In this sort of situation, the full measurement of the pixel includes all five numbers, and any algoritm that affect pixels would have to take into account all five numbers (just as any operation now must account for all four exsisting pixel measurement numbers). Indcidenally, alpha, in the way it as been used would be C*T.
Also the painting algorithm would have to use two different algorithms for strokes on top of another opaque area in the layer and for strokes in the area in the layer where the layer mask makes it transparent. While Gimp could do this for me it would also include the overhead of accessing two drawables simultaneously which is not really good.
I think what I said above addresses this.
-- Dan
