Had an offline discussion with chrishtr@ today, this bug is due paint order issue with fragmented effects.

For example:
<div style="width:100px; height:100px; column-count:2;">
  <div style="opacity:0.5; height:200px;">
    <div style="z-index:0; height:200px;">
    </div>
  </div>
</div>

The middle element will have two fragments F11, F12, and effect node E1, E2 for each fragment, also the innermost element will have two fragments F21, F22.

In PaintLayerPainter we would paint these fragments in the following order: F11, F12, F21, F22. In effect stack diagram:

 F11   F12   F21   F22
[ E1 ][ E2 ][ E1 ][ E2 ]

This breaks the contiguous (atomicity) requirement of effect nodes. In SPv2 mode, PaintArtifactCompositor would detect such anomaly and commit suicide. On the other hand in SPv175 mode PaintChunkToCcLayer would try its best to behave same, in this case, apply the effect twice as if they are two different effects.

SPv1 just doesn't fragment effects, thus not subject to this issue. The W3C spec isn't clear about the interaction between fragmentation and effects, but IMO fragmented elements generate multiple boxes, and each boxes should independently have their own stacking context effect instances. i.e. I think the SPv175+ model feels more intuitive.

The long term solution is that we should adjust paint order so that the fragments will paint in order of F11, F21, F12, F22. That will be automatically done once LayoutNG is done.

Before LayoutNG, we can deploy a midterm fix to make PaintLayerPainter::PaintChildren() fragment-aware, so that each fragment will call PaintChildren(), and the child painter should only traverse child fragments that are parented by the designated fragment.

For the short term, we concluded that the combination of multicol and effects is probably not common enough to block SPv175 launch. (we'll live with it for a while)

Re very short term, I think it's ok to not fix this test and leave it slightly
broken.

Probably ok to not fix this issue for CAP, and make PAC not crash for this situation. Action item is to check that PAC behaves acceptably in CAP mode
for this example.