I found on the web:

Unlike Debian based distributions, Red Hat and distributions based on it 
organize lib directories in a way that lets you install a 32 bit package 
of .so files on an x86_64 system without any conflict with the 64 bit 
build of the same package, which may also be installed.

AND:

The Debian system dynamic library linker has been modified so that when 
a 32-bit application requests access to a library, Debian provides the 
32-bit version of the library if it is available instead of the normal 
64-bit version that the native applications require. This works if the 
ia32 packages which provide a sub-set of standard Debian libraries 
compiled in 32-bit mode have been installed.  (NB:  I am not using a 
Debian distro, but the SL 6 RHEL 6 distro.  The quote is for clarity.)

End quote.

Unfortunately, this does not always seem to be the case in direct 
practical experience.

Two questions:

1.  How to install the SL6 release so that the System -> Administration 
-> Add/Remove Software will list both the 64 bit and 32 bit libraries? 
I have tried sl-release-6.0-6.0.1.i686.rpm and this does not cause these 
library choices to be displayed.
I suspect this is because from the sl.repo file, the stanza 
name=Scientific Linux $releasever - $basearch always puts the actual 
base kernel ISA into the $basearch, so only X86_64 appears.  I tried to 
make a separate repo file that would force the IA-32 libraries to be 
listed, and although I enabled the new repo using System -> Software 
Sources in the Add/Remove Software application, no such library RPMs 
appeared.

2.  Many packages that must be built from source rely upon configure and 
for various reasons, paths such as /usr/lib , not /usr/lib64 that is the 
X86-64 path, appear.   This is an issue with appropriate scope specific 
polymorphism.  Will the following idea address this issue?  Two unique 
paths for libraries and include files:  foo32 and foo64 with foo being 
the appropriate path identifier.  At the actual time when a decision as 
to which foo to use, set foo to either foo32 or foo64 but let the 
application (e.g., configure and the files needed for configure to 
"configure") only find foo .  Thus /lib could be either /lib32 or /lib64 
depending upon whether a 32 or 64 bit application was needed, etc.  This 
is still much simpler than a chroot mechanism of keeping two identical 
operating systems and application environments on the same machine, one 
IA-32 and the other X86-64.  Obviously, utilities such as ld (mentioned 
in a Debian context above) must be aware of the differences, as must 
compilers when creating appropriate object or executable file internal 
headers.

Yasha Karant