Unfortunately, upstream doesn't really notice if 32-bit x86 breaks. This isn't just a kernel problem; glibc managed to push out a release back in 2017 that broke memchr on 32-bit Atom in a way that tended to cause programs calling it to segfault. It turns out that amongst a few other things, including Python, the glibc build process itself relies on memchr working... I don't think they actually tested the code path in question after modifying it.

Of course it was tested [on the developers' x86_64 laptop(s)]!

Sure, but the ones that pay the bills are servers and companies which don't care one bit about i386.

Agreed, however open source has always relied on enthusiasts for consumer-grade hardware support.

The really fun part was when they launched the first 64 bit Atom CPUs (Bay Trail) and then a bunch of them got shipped with only 32 bit UEFI and cannot boot in 64 bit mode.

They have to _boot_ with a 32-bit UEFI bootloader, but can run a 64-bit kernel and userland. Fedora Linux even allows for this while keeping secure boot on; Debian supports it as well but the interaction with secure boot is buggy, so you need to turn it off. Not sure about other distros, however.

Early 64-bit Intel Macs also shipped with a 32-bit UEFI limitation, but they were able to boot into a 64-bit system.

Jesus was closer to dinosaur times than we are to 2015.

Casual computer users don't buy new computers each year. Pretty sure set top boxes and routers with 32-bit x86 processors have been sold since then, too.

Are you Him?