The backdrop blur is unrelated to the surface properties of the elements underneath: it’s about the frosted glass refracting light, and some of that light it refracts comes from beyond its bounding box, which a naive backdrop-blur won’t observe.

Frosted glass doesn’t pass through light of objects that are simply near by it. It doesn’t make physical sense. I understand the defect, but neither does this solution correctly fix the problem.

Note the circle before it intersects with the rect, without accounting for pixels beyond the bounds, the blur is incorrect because the kernel doesn’t take into effect the circle.

Note the blur after extending the kernel beyond the visible bounds. While the blur is correct, the albedo of the shape passing through the rect no longer makes sense. The circle is not emissive, and yet despite this, you see the blur of the circle behind the rectangle without it intersecting in a full-bright environment. Why can we assume the environment is full-bright? Because there is no lighting. Only albedo.

Neither are correct.

I have an inking of what you’re getting at now. I want to try modelling it with full ray tracing now (in the absence of a piece of actual frosted glass!), to convince myself if you’re right (I’m not sure one way or the other), but sadly I doubt I’ll get to it any time soon.

I used physical samples of pebbled glass, curved glass, and clear glass. You can get the same effect using curved glass because of how natural light bounces off of the surface of the subject object and onto the glass, but you don't get this pronounced of effect with a flat panel of glass, frosted or not.

It's too exaggerated for, say, a kernel of 32px.

That article covers a bug in implementations of blurring in browsers. It shows how when a 200px red circle is fully covered by a blur with radius 16px, today you will see a 232px sized blurred circle. But when the circle is shifted down from under the blur, so there is one pixel of space separating the two, you would still expect to see 15 px of blurred red circle. Instead it goes 18, 17, 16, 0, 0, for every successive frame. That’s a bug.

It’s not an implementation bug, it’s a deliberate design limitation in the name of performance. (There are quite a few practical limitations on backdrops in the name of performance.)

It’s not impossible that this will be adjusted in the future in some way, like how browsers quite some years ago shifted to premultiplying colours so that a gradient from white to transparent doesn’t go through semitransparent grey, but browsers are acting according to spec.

It’s an implementation limit of a limited backing layer size. So no, it’s not a bug. But neither solution correctly blurs objects that insect with the layer.