lepr

You already know that the rendering of masked groups is broken - you even name your file with the words "mask bug" - so it is unsurprising that the rendering doesn't fit into my proposed model. A masked empty group should have no effect on a document, just as an unmasked empty group should have no effect. In the case of an empty Passthrough group, the passed through underlying composite is effectively non-existent since there is no child to provide the alpha greater than zero that toggles on the contribution of that passed through composite. In the case of an empty group with any other blend mode, there is simply nothing to blend, by definition.

Not only pixel layers. Try some other types of layer/object.

I'll leave live filters out of the following statements because Photoshop does not have standalone live filters like Affinity (Photoshop's live filters can exist only when clipped to a Smart Object) as far as I remember. Affinity's Passthrough and Photoshop's Pass Through are the same when there is entirely adjustments in the group or entirely non-adjustments in the group. There's a difference between the apps when there is a mix of adjustments and non-adjustments in the group, but Affinity can be tricked into behaving like Photoshop by putting a white Multiply fill layer as the lowest member inside a Passthrough group.

In all cases of Passthrough, the underlying composite image is passed through to the group. That is why we can use the trick of a white Multiply fill layer as the lowest child of a Passthrough group so that filters/adjustments then affect the appearance of the underlying composite when there are also non-filter/adjustments in the group. As I said, "The name is Passthrough because the underlying composite image is passed through to the group."

Passthrough does not involve a propagation of group properties to child layers which you suggest. Elementary testing proves that idea wrong. A Passthrough group is rendered as if it has Normal mode but containing a virtual lowest child layer which is equivalent to the composite image lying below the group wherever any child of the group has alpha greater than zero. The name is Passthrough because the underlying composite image is passed through to the group.

you're welcome

Instead of copy and paste, press cmd-j to duplicate.

You: "In passthrough [...] when you change the group gamma, too this gets ignored and has no impact." Me: "[...] the blend gamma of a Passthrough Group does have an affect [...]" My statement contradicts yours.

All three bullet points contain garbage. The author either doesn't really understand that aspect of the software, or they are very unskilled at communicating their knowledge. The third bullet point will be referring to the trick of using a Multiply mode white fill layer at the bottom of the layer stack inside a Passthrough mode group.

In RGBA/8 and RGBA/16 documents, the blend gamma of a Passthrough Group does have an affect if you ensure there is an actual layer/object below the Group and not just the canvas. This thread has become a mess of poorly controlled experiments or ideas being posted as facts without actual testing which easily proves the ideas wrong.

If a high impact issue remains unfixed for a decade, there is absolutely zero prospect of a medium impact issue being fixed.

The preview ignores the actual choice of Output ("Selection" in your case) and shows the result for "New layer with mask", which involves edge decontamination.

Leaving aside RGBA/32 documents where Blend Gamma is ignored and RGB values are used "as is" in blending, the following concerns RGBA/8 and RGBA/16 documents. The upper layer's Blend Gamma value is factored in, yes, and I did not assert the opposite. However, your claimed linearisation of upper and lower layers before blending and then gamma encoding of the blending result is not performed, and that's why your spreadsheet does not give the same results as Affinity. The upper and lower layer's RGB values are exponentiated by (2.2 / upper Blend Gamma) before blending, and the blending result's RGB values have the inverse exponentiation applied to them. The measured results in Affinity verify that, allowing for decimal rounding errors. Notice that that implies no exponentiation happening in the case of the default Blend Gamma 2.2, and the measured results in Affinity verify that the RGB values are used "as is" in that default case. Contrast that with your assertion that, in the case of Blend Gamma 2.2, RGB values are exponentiated by 2.2 before blending, and the blending result's RGB values have the inverse exponentiation applied to them. The measured results in Affinity prove that wrong.

Simple solution with no tweaking nodes, expanding strokes, merging shapes, filling holes etc.: leave the strokes fully opaque and just reduce the opacity of the Group in the Layers panel. shadow.mp4

My response to you just 8 weeks ago: