Well, that partly answers question 1 as well. You see, I had to install the full 64-bit glibc in order to build barbarella (that's the program that displays my button bars); I'm well aware that this installation replaced the solibs one from set a. So I think I would need the full glibc multilib installation to match. I don't see any way I would require a multilib gcc though. I'm not going to build any 32-bit software.

But how does Slackware deal with this kind of overlap between packages? For example, I now have both glibc and glibc-solibs. If an update came through, which package would be responsible for updating the runtime libraries?

The exact same glibc packages exist as pure 64bit packages already on your system. So, if you "upgrade" the stock packages with the multilib ones, it'll simply replace the pure 64bit packages with their multilib counterparts.

Yes but what happens to the original packages when a different package takes over responsibility for the files? When I look in /var/log/packages, I see:
glibc-2.23-x86_64-4_slack14.2
glibc-i18n-2.23-x86_64-4_slack14.2
glibc-profile-2.23-x86_64-4_slack14.2
glibc-solibs-2.23-x86_64-1

glibc-solibs is the originally installed runtime-only package; the other three are full libraries out of set "l". But when I installed them, the glibc-solibs package wasn't removed, and presumably installing the multilib versions won't remove the pure 64-bit versions. If glibc changes upstream, all these packages are likely to change at the same time. So what exactly happens to the files when I do a general upgrade?

upgradepkg will overwrite any files that are the same and then it will remove anything that doesn't exist in the new package. You will end up with one entry for the package in /var/log/packages/

If you run installpkg, it will overwrite any files that are the same, but will keep the old files in place (which depending on the package, could cause breakage). You will end up with two entries for the packages in /var/log/packages/.

If you decide to remove a package that shares a file with another package, removepkg is smart enough to only remove files that are only used by the package you're removing. If that file exists in another package on /var/log/packages/, it won't remove it.

The package glibc-solibs is a subset of glibc-2.23 and contains the same files.
You actually only need one of them, but as long as they're the same version it doesn't matter. The same goes for the "compat32" versions of these packages, they ARE the same libraries (and files), but then compiled in 32-bit mode (and AlienBob makes sure they will NOT overwrite the 64-bit ones, which the "pure" 32-bit packages would do).
Note that in YOUR case the glibc-solibs is still the original, as distributed, build (-1) while the full library already has been upgraded (to -4_slack14.2) so the libraries AS installed by glibc-solibs have already been overwritten by the ones from glibc-2.23

To avoid confusion it may be wise to removepkg "glibc-solibs" and then re-install "glib-2.23" (to make sure all of ITS files are still there - that's what upgradepkg does too). the command upgradepkg in effect does
"install the new package",
"remove the old one" and then
"re-install the new one" once again.

BTW: Pat _does_ have a "glibc-solibs-2.23-x86_64-4_slack14.2.txz" package too, for those who do not need the full 2.23 package but just the run-time so libraries.

Whichever of the two was installed LAST, as the one is just a subset of the other (which is actually true for all of the <something>-solibs packages, it is just a runtime-only subset of the full development version of that <something> package). As the name -solibs- suggest those packages will install only the .so libraries OF the full package and i.e. not the header (include) files and others you would need for developing/compiling applications.

So for instance it is well possible to have the full package for 64-bits but only the solibs compat32 one when you only need the latter just for running 32-bit stuff.
But make sure they're the same version (and beware: a later update to the 64-bit version will NOT automaticcally update the compat32 one too!).

In other distro's you often have a runtime package and a separate -dev or -devel one, but Pat normally packages the full version by default, inclusive of all development files and only in a few cases there's a separate -solibs package - for runtime usage only.

That's certainly what I'd do if it was anything but glibc. But wouldn't removing glibc-solibs, even temporarily, bork the whole system? I've been studying the install script for the 32-bit glibc-solibs and it doesn't just delete the old and install the new as most Linux software updates do. It puts the new files in a special holding directory and runs ldconfig on them individually to ensure that there's always a full working set available. Only then do the old files get deleted and the new ones renamed.

No, after sleeping on it, I think the safest option would be to leave the old 64-bit libraries on the installed list, but blacklist them so that they won't be seen by slackpkg. Then there's no danger of the wrong package being updated.

No, because all of the really needed .so files will still be there through the glibc-2.23 package. In fact they ARE the ones from that package as they have been overwritten at the time you upgraded that package to the -4_slack14.2 build.
The reinstall is only to make sure that all of the symbolic links and ".new" files have been processed correctly as they are done by the post-install script (doinst.sh) and the undoing of that in removepkg isn't always without faults.
In fact, like in rpm's, it would have been better to have got a "doremove.sh" script too, now removepkg must guess. from the to be removed script, which actions from that it should undo.
But Pat is very safe with glibc, because otherwise "upgradepkg" wouldn't work on a running system either.

And if you _really_ want to make sure you can use upgradepkg to upgrade the -solibs package to the full one with the commandwhich means: upgrade glibc-solib by re-installing glibc-2.23 in its place. But it does the same thing as

Another option, of course, is to upgrade alle -solibs packages to exactly the same build as the full package. Then all of the shared objects are referenced by TWO packages so will not be removed until BOTH of them have been upgraded to the newer version/build.

PS: Slackware's package naming is:
PACKAGE-NAME - version - architecture - build [optional with a filename extension]
in which PACKAGE-NAME _can_ contain additional dashes, so
glibc-solibs-2.23-x86_64-1
has as name "glibc-solibs", version 2.23, architecture x86-64 and build 1, while
glibc-2.23-x86_64-4_slack14.2
has a different package name "glibc" and build 4_slack14.2 (rebuild #4 for slackware 14.2), but version and architecture are the same.

That didn't work for me, probably because I don't have the actual package any more. I have been installing these things with slackpkg and it's currently configured to delete packages after installation. Maybe I should change that.

Anyway I took my courage in both hands and removed glibc-solibs, then installed the multilib version. And everything still works. But now I really must install the rest of glibc-multilib, because having a version shift between runtime libraries and their headers could cause problems if I need to build something.

PS: done that and it all went smoothly. I was able to use that % thing; it works if you have the package locally.

Don't you think that this thread has morphed? Should this present topic not be a new thread?

I don't know how to split a thread, so my suggestion is that we bring this one to an end. Because I have just printed a sheet out of my Brother printer and that means that I have effectively created a complete replacement for Crux.

When I am a little more confident, I will get rid of Crux and use fsarchiver to transfer Slackware to its final home on /dev/sda1.

May I again thank the Slackware community for rallying round and giving me so much good advice.

You can use slackpkg+ to keep multilib up to date if you want:
https://docs.slackware.com/slackware:multilib?s[]=multilib#keeping_your_multilib_up-to-date

I certainly don't speak for the whole community but I do imagine the feeling is similar that
1) Congratulations on your well thought out and executed efforts
2) "Good advice" is just one of the many benefits of Slackware
3) It seems you are quite capable of joining in that effort to provide considered help to others.

Unlike some other distros, this is not one of "the blind leading the blind" since Slackware has actual qualification requirements beyond "point and click here" ;)