When calculating a bounce, Construct has to calculate the normal of the bounced surface from an arbitrary collection of objects. This is quite a difficult thing to accomplish, and it uses an approximation algorithm which looks at nearby objects. This means the objects very close to the edges take in to account the side barriers when computing the normal of the collision, which causes them to bounce at a different angle. This is the kind of thing which is far too troublesome to ever change, since likely hundreds of existing Construct games already depend on the bounce calculation working the way it does. Even improving the accuracy could cause some other games to start misbehaving. So I don't think it's worth fixing this; it's a minor quirk of the bounce algorithm, most people seem happy with it the way it is, and backwards-incompatible changes can cause borderline revolt amongst users, so closing as won't fix.

I appreciate the explanation for why this is a no fix; that said, I could understand if we're talking about a pixel or two gap resulting in a the angle being off by a few degrees, but there's a clear 4px gap between the bullet and the border resulting in a 45 degree deviation from the expected angle, off flat orthogonal surfaces, which isn't exactly a minor quirk.

I recognise that the hope is many users will import their existing C2 projects over, but doesn't C3 being in beta offer an opportunity to clear up these sort of issues with the behaviours and get them working as expected?

IIRC the tolerance is based on the distance it moved last tick, so actually depends on the speed. This is because it only has two data points when calculating a bounce angle - a known colliding point and a known not colliding point, and it works from there. So the tolerance is probably 10px or so.