What happens during overlap, is something you control fully, at every step. (Except when using this with MSAA, as that is implementation defined) How intersections happen when blending shapes of multiple draw calls or multiple quads is defined by the blending function you set before issuing the draw call. In WebGL the call is blendFunc() [1] and there are a bunch of options.
How to blend multiple shapes on the same quad, within a draw call is shown in the section "Drawing multiple?". There you fully control the intersection with the blending math.
Finally, there is always the gamma question, which is true for all AA solutions. This is not covered in the post, but that might mess with the results, as is true for any kind of blending.
[1] https://developer.mozilla.org/en-US/docs/Web/API/WebGLRender...
I think the point is that a correct analytical result needs to be computed for all shapes at once. You can't composite overlapping shapes individually, since the alpha value (subpixel coverage), even if analytically correct, is lossy; you lose the information about the exact subpixel geometry, which is needed to do correct compositing (eg. does this shape completely occlude this other one within this pixel?). The standard Porter-Duff blend function assumes the subpixel geometry is a uniform random mist, which is not necessarily a great assumption for AA.