I wonder if that’s because they’re just running an older version of WebKit/blink.
"Chrome's" rendering in many cases is going to be whatever hardware accelerated stack (probably Skia + your platform's particular hardware API) is rasterizing the page. Headless rendering as found in a page scraper bot is more likely to be using software rasterization and might be using an entirely different API. Chrome has a few command line flags that can push everything through different rendering paths and you can get different results from it.
Blink (the HTML engine) is still going to push the same drawing commands to all the backends. Winding rule order stuff might be different if a backend is buggy, but things like this shouldn't be different.
I wouldn't be surprised at all if there's a drawing command that's having a negative number passed to it in a place where it doesn't expect negatives. I wouldn't be too surprised if different backends handled this "undefined behavior" differently.
Nah, this will all be handled within Blink. The drawing command will literally be told to draw polygons in the specific places in the coordinate space.
"shouldn't", but historically I've observed that different backends have different behavior for filtering (of bitmaps and layers) and for text rasterization. Wouldn't be surprised if geometry rasterization could be different too.
Maybe chrome/blink require too much ram so they used WebKit /s