Okay, I didn't think about the move part...
My approach is that 32-bit becomes the exception, not the rule. More and more software has issues with 32-bit, most packages are only tested on 64-bit nowerdays. And, yes, a 32-Bit install on an AMD64 system would certainly qualify as well: every x86 processor has Real Mode (8086), 16-Bit Protected Mode (80286), 32-Bit Protected Mode (i386) and Long Mode (AMD64). Running a modern x64 system in 32-Bit Protected mode would be a 32-bit system, would it not? (But who would do that?!?)
You might refer to the x32 ABI? This is technically Long Mode also, and I think it's also not that well supported. That would have to be excluded. (Be its own forum even?)
The Linux kernel still supports the 486 and up. Like on PPC, with 32-Bit it's getting harder to make things work. For every less and less used system, like PPC and PPC64 and in this case 32-Bit-x86
aka x86-32, a lot of code is not checking the system's capabilities correctly, e.g. I've read that rust uses SSE2 on i686 even though it might not be available (see
Web browser options for PPC64? reply by Hu).
It's just a suggestion. To me it seems that 32-Bit-x86 is becoming more and more what PPC/PPC64 already is. Look at how many people are actually using it: less and less.
BTW, IA-32 ("Intel Architecture 32-Bit") includes x64/AMD64, hence the name x86-32 for specifically 32-Bit-x86. This also distinguishes it from x32 (the ABI).