Re: what about RPi?
well that's the point, the IMPLICATION of 'x86' is why I ask the question, "what about RPi"? But if all they meant is x86, then there may be some point to that, except for us legacy computer users who might have an old Toshiba laptop laying about that still works, doesn't support PAE, but has plenty of RAM and disk space to run Linux (and works well for testing certain things, particularly bluetooth connectivity and microcontroller-related serial port stuff). Oh, wait, I _do_ have one of those!
They're also forgetting it's possible to load a 32-bit build onto a 64-bit CPU... (so testing on newer hardware is STILL possible).
In any case, there's also another bit of 'forgetting' going on here: we forget that 64-bit binaries run SLIGHTLY SLOWER than 32-bit binaries, because the data and instructions are (by default) BIGGER than they would be for 32-bit, so you suck more RAM through the pipeline. The binary files are also slightly larger, and memory requirement is slightly higher.
Further, how many programs _NEED_ >2Gb of RAM space in order to operate? Not a lot, yeah, unless they're coded by _IDIOTS_ that waste resources, assuming "no limits", and/or rely on 'garbage collection' to compensate for a lack of knowledge of 'malloc' and 'free' (Mozilla, that's YOU).
In any case, the RPi and other 'embedded' platforms (x86 included) are reasons NOT to dump 32-bit in general. But, we've seen bad decisions before. I suppose a FORK will happen, just like for systemd, just like for Gnome 2 (now MATE), just like for Open Office and 'MySQL' (when they were sold, so "something" would STAY OPEN).
/me points out that "faster hardware and more RAM" is *NOT* justification to use inefficient code, because you CAN now - Micro-shaft does EXACTLY that, and we hate it, don't we? Rather, it should be reason to produce MORE inexpensive hardware (with yester-year's specs) that can be used for mundane purposes, like embedded systems basically are.