My duallib setup is simply two clearly obvious environments. It gives a high degree of certainty that the tool chain is operating as desired. It's basically two separate root trees, each having one library set appropriate for it. Use chroot to enter the one desired. This way you know what you get, and don't have to depend on packages to properly build Makefiles that properly pass options to get gcc to generate the correct code.

A few points on that:

32bit libraries are to be installed in lib/
64bit libraries are to be installed in lib64/

If you tell gcc that your library path is lib/ then you get 32bit libraries, otherwise 64bit.

If you installed the packages Alien Bob created, you'd have /etc/profile.d/32dev.sh and /etc/profile.d/32dev.csh from the compat32-tools package.
If you compile in that 32bit environment, you get 32bit applications. Otherwise you get 64bit applications, unless explicitly stated that you run and compile against 32bit libraries. So, in fact, due to FHS there is a distinct separation between 32bit and 64bit environments, at least as far as libraries go. And otherwise, Alien Bob made sure that it is very well possible to have the binaries separated, so you'd be sure you have a 32bit or a 64bit binary.

And if you still wonder what the result of your file is, 64 or 32 bit: you can run "file <filename>", with that you can see what you got. I don't see your problem.

All that 32-bit vs. 64-bit libraries determine is which libraries your code is linked to. It still doesn't specify what code the compiler generates. There are compiler options for that. You can end up with a mix. The "file" command cannot sort that out.

Complicate this with the fact that not all distributions use the same library naming scheme. Some, for example, put the native libraries in /lib and the alternates in one of /lib32 or /lib64 and symlink the other. If you want to make dynamically linked binaries for all Linux distributions, you are in for some surprises.

Multilib is a hack.

Now the big question is this. You have some source package that was downloaded. You have a multilib setup. You want to build this source package in both 32-bit form (so you get binary stuff that runs on machines that are 32-bit only) and in 64-bit form (so you get maximum capability on machines that can run 64-bit). Reading the instructions for the package, which claims it has been successfully compiled on dozens of different platforms and architectures, it just says to do "./Configure && make && make install" while logged in as root, and it will work and generate code for the host architecture. Will you get 32-bit code or 64-bit code (notice carefully that I am not asking what library will be linked) when you do this?

There are a number of source packages that do make an effort to be cross compile capable. Often they are packages that need to know (e.g. binutils). Packages like gcc are especially tricky, as you could be running on architecture A, building a binary of gcc intended to run on architecture B to produce code for architecture C. But most packages are not so helpful. There is no provision in their build systems to specify an architecture directly. You have to work around that somehow. There are multiple ways to do that. I've done many of them. But what I have always found to be the most reliable is to entire avoid any form of cross compiling or cross linking entirely, and build everything natively. When building a system for a new architecture, cross compiling and cross linking is unavoidable to start with. But once the new system is built for the target architecture, the next thing to do is rebuild the whole system yet again, natively on itself. Repeat until two passes have no differences.

While 32-bit and 64-bit for any architecture class might be considered by some as the same architecture, they are still, technically, different. You might have a single compiler binary that can build for either. You might have both sets of libraries. You might have a CPU that can run either set of instructions. And you might end up producing results with a mix that you would not be able to see.

I've worked on multiple architectures for years. At the very minimum, testing in pure environments is essential to be sure your compiled and linked results are correct for that environment. So you need to have those environments, anyway. You might as well use them for building, too. In cases where the environment is simulated (for example using QEMU emulating an ARM CPU), that might be an expensive way to build, and be desirable to avoid. But for 32-bit and 64-bit, on a machine that can handle both, that argument does not apply. Doing builds on a duallib/dualroot system by means of chroot into the desired environment gives the greatest confidence level that the build is correct for that environment.

The only reason I've had to avoid 64-bit Linux has been support for "Fake hardware RAID". Slackware current now supports Intel Matrix Storage Manager fake RAID. So, it is only non-Intel RAID with a mixture of operating systems (Windows / Linux) where one might want to stick with 32-bit Linux and the "dmraid" program. I have seen 64-bit packages of "dmraid" but I haven't seen one for Slackware yet. I was not able to figure out how to build a 64-bit "dmraid" from sources, if that is even possible.

I successfully installed Slackware 64-bit on my Intel fake hardware RAID using "mdadm". After installing Alien Bob's multilib packages I've had no problem running 32-bit applications including WINE 32-bit.

32-bit applications that require kernel modules or come with drivers might not work with multilib. For those applications it's necessary to get the 64-bit versions of the modules or drivers that interact with the 64-bit kernel.

What is this "fake hardware RAID"? How does this differ from software RAID?