I can confirm Maxy's fix as being working code, and I think this bug is fixed - with reservations. The solution we have now might cause more confusion for users in the long run than it will solve if it's the only merge command.

I'd like to work on a more judicious "Merge Visible Layers" command, but that's going to require RGBA compositing and a background that can be turned off as needed. But that's a separate bug report. Having a separate "convert to normal" command which doesn't perform a merge is a Very Good Thing to have, for pure interoperability reasons. Kudos to Maxy for that!

There are good, open questions to answer for OpenRaster about how (or if) to specify compositing operations for plain old viewing too. A survey of how common software apparently does things is needed, given the observed Gimp behaviour :)

I have reworked the rgbu branch a bit and pushed it to master.

Depending on the mode and effect, background pickup can be minor or quite notable. There is a bit room for improvement, too - the alpha is increased a bit more than strictly required when merging. Maybe I'll fix that. But I think in many use-cases it simply isn't a problem.

I consider this fixed, please test.

Andrew: You shouldn't have to move any layers. There are already >1 areas of paint which are invisible before the merge (because it's being applied in Lighten mode and is not lighter than the BG), and which show up after the merge. If it really does look the same before and after, that's a .. anti-bug? (seeing as this is a bug report for how it DOESN'T look the same before and after)

Martin: IMO the appropriate way to handle transparency control is to provide some kind of masking, where the alpha channel of one layer masks the layers atop it. I think it's not a big deal that the merged paint could be solid-er as long as a way to do that is on it's.. way, especially considering that some effort is made to avoid solidifying. In any case I absolutely agree that it's the most predictable + reliable choice, and transparency is not a big deal.

GIMP-2.8 has the same behaviour as 2.6. Not sure about 2.9 (development version), as GEGL introduced some changes in the way compositing is put together.

Out of curiosity, what would the code do in this case I attached? (where the best solution seems to be to decrease alpha to 0 for areas of no visible effect)

To be more precise: the solution that I have proposed (and implemented in a branch somewhere) doesn't make all strokes solid. How much it "solidifies" the layer depends on the blending mode and colors used. The result is always a "normal" layer, and it tries to increase the alpha only if the same result cannot be achieved by changing the colors.

The implementation is just a bit messy, maybe I'll clean it up for master. IMO it's the sane thing to do, everything else will be predictable only to very advanced users. It also has the advantage that it can convert any layer into "normal" mode, side-stepping all the inter-application compatibility headaches (except the one about linear light).

In particular, though the layer mode behaves correctly, interaction with background is wrong: pixels where there is no content in the layer beneath are applied as if they were using Normal mode.

Example document attached -- compare the result of merging the layer 'enlightenment' down with the display MyPaint gives before merging.

This may occur with other modes -- in particular I suspect Darken -- but I haven't had the time to do further tests yet.