Yes. I recycled my last 32 bit unit years ago (a netbook).

Still got one intel ATOM, can't use 64bit instructions.
But I don't use it anymore, since the Turion laptop just landed on me.
What are we talking about here, dropping 32bit support in Slackware?
Wouldn't that make multilib a new Slackware requirement?

I remember that Mr. Volkerding explained long time ago that the Slackware64 will be kept pure 64bit even in the eventuality of dropping the 32bit variant. And Mr. Hameleers explained long time ago that he will never maintain a 32bit set of Slackware packages, then dropping the 32bit Slackware would result also in the dropping of his Multilib.

No. I was remarking that I don't own any 32 bit hardware. I know some folks have use for 32 bit support. I have no problem with Slackware shipping a 32 bit version of Slackware and or offering 32 bit support.
Mr. Volkerding will make the call about how 32 bit hardware/software is supported.

OK, it just sounded like a hint that all 32bit is obsolete..
And you do have Arch on your list, where only 64bit with multilib is supported.
So I'm just hoping we don't end up with a multilib-only installer, even though it would not affect me since my only 32bit use case is wine.

Proprietary printer drivers tend to be 32-bit or at least to need 32-bit glibc. Certainly the Brother ones do.

Dropping 32bit comes up in the gaming industry every once and a while. Video games were slow to move to x86_64 and are usually shipped precompiled, so you have a lot of games from 2010 to 2015 that are still 32bit only.

If modern OS's drop compatibility, this raises questions outside the software community in terms of property ownership. In all honesty even if distro maintainers stopped shipping 32bit ports a company like Valve would probably maintain a set of libraries just to fulfull their customer's expectations.

Nah, they'd probably port all that to 64 and charge again for "remake" of the same thing you already have.
Either way, it's in their best interest and no concern of mine.
I only liked diablo, starcraft and a few more when I played games, which is now MS property IIRC.
So, mostly irrelevant at this point.

Edit:
To make it clear I did buy quite a few of them CDs in the past so I know how it works with games companies.
One can't update starcraft (1) CD to most recent 'remake' version, without buying it again.
It was like that even before MS and I don't see why it'd change now, or why valve would not do the exact same thing.
OP did not specify what software he's having trouble with, but I suspect it's something like that.
Whether or not valve is to be trusted with hosting parts of slackware, well..
I don't think it's very wise, but it's definitely not up to me to decide this for others.

M$ windows is multilib, or else it has the name of being 64bit when it is in fact 32bit. So it would hardly occur to the normal luser/manager that something could be 64bit and not 32bit. So 32bit M$ drivers work, but 64bit drivers cause hassle.

I personally feel all OSes should be multilib, but sadly that is not the case, especially in linux. I wouldn't personally like to try a multilib LFS. The fortunate thing is that a version difference between 64 & 32 bit libraries so rarely comes back to bite you.

It did have some sort of multilib since the first 64bit release.
It's why it totally makes sense that everyone who ever used it expects all systems to have one.
But it's still utterly useless to host multilib if you don't have any 32bit program or driver installed on it.

Yeah, but Windows is binary-only. You don't get any source code with it, nor compilers. And most of the user base doesn't add those things to Windows.

But you're right. It has taken Microsoft a long time to jump aboard the 64 bit train, and even now some 64 bit software doesn't work properly in Windows. Most things do though, and if I'm given the choice between 32 and 64, I'll always try the 64 bit version of something first.
In the modern world, there are very few reasons multi-lib is truly required under Linux apart from gaming. Hazel mentioned proprietary Brother printer drivers above, but I've found using 64 bit generic PCL drivers works well for many Brother printers because they generally support PCL.

Even so, for gaming there are projects like ScummVM, which itself is 64 bit, but will allow you to run 8, 16 and 32 bit games without multi-lib on your Linux system. Their compatibility list is quite long, and continuously growing.

Likewise for DOSBox... It can be compiled as a straight 64 bit binary, but will run pretty much anything which ran under DOS (Including Windows 3.x) on Linux without multi-lib.

I would only run 32-bit os on a 64-bit machine if it had under 2-3 gb ram
and the applications I needed worked on it. Otherwise I run the 64-bit on them.
Some newer software is 64-bit only also. So weigh the needs on the machine use.
32-bit uses less ram than 64-bit. 64-bit software can be faster on 64-bit hardware.
Some websites also don't work on 32-bit too.
Somehow this topic turned into an OS discussion of windows vs. linux,
rather than the OP question.

Everyone is on the same page really - M$ is very slow to go 64bit, things like Adobe Acrobat & Macromedia Flash (both R.I.P) never did. Linux, otoh, just jumped in and went teetotally 64bit. I'm just irritated by the libs thing - any time I grab something to try, I resent this checking with 'file' to see if it can be run. Oh, there's wine as well which is a 'must-have' for me (for a 32bit program), which is given away, and is designed for people too poor to upgrade. These often are in places like sub-saharan Africa. So the 2016 version ran on a '386; the 2019 version requires a '586, but retains compatibility with the 2016 version.

I did try ScummVM. Back in the day, I needed Windows for my Electronic hardware gear, and linux was in it's infancy. I bought each Space Quest game for my kids as they came out, and my 3 boys would sit around the pc (when I wasn't repairing some mission-critical PCB) and play the latest game. Turns would change whenever someone lost a life. They would often laugh their heads off when they were killed, instead of being bad tempered or sulking. 30 years later the youngest gave me sq1-6 in a .rar and it needed scummvm and some audio compiles, but it was pretty sad on the games. They relied totally on the mouse, and the mouse didn't work near screen edges.

Controls depend upon which game you're playing. Why did your mouse not work near the screen edges? I've not had that problem.

I have windows 7 in thye VM now, and still have the .rar of 1990s games. I can try for it. Windows 7 hogs about 2.5GB of ram just sitting there, so I can probably do it within the 3G I can allot to it.

I, like you, prefer 64bit OSes. But my RazPi 4 came with a 32bit OS & software, and I was surprised it just worked so well. Compiling is tedious on the RazPi, because deps are AWOL, code breaks and compiling is deadly slow. Guys reported amazingly long times - over 24 hours for firefox, etc. But that was the same, 32bit or 64 bit.