Rationale: To support multiple versions of one piece of software without resorting to starting a separate prefix (such as e.g. /opt/csw/postgresql90).
Single-version layout
Binaries:
/opt/csw/bin/fooapp
/opt/csw/bin/sparcv9/fooapp
Libraries:
/opt/csw/lib/libfoo.so.1
/opt/csw/lib/sparcv9/libfoo.so.1
Development files:
/opt/csw/include/foo.h
/opt/csw/lib/libfoo.so
/opt/csw/lib/sparcv9/libfoo.so
Shared files:
/opt/csw/share/foo/...
Deep multi-version layout
Binaries:
/opt/csw/bin/foo/1.0/fooapp
/opt/csw/bin/foo/1.0/sparcv9/fooapp
Libraries:
/opt/csw/lib/libfoo.so.1
/opt/csw/lib/sparcv9/libfoo.so.1
Libraries have their own mechanism to handle multiple versions: SONAMEs. Multi-version placement for shared libraries is the same as single-version. All libraries should be kept in /opt/csw/lib, unless it's technically impossible, e.g. due to SONAME conflicts. One example would be a GCC version of a C++ shared library. Problem to be addressed. (One way would be to modify the SONAMEs of GCC-compiled C++ libraries.)
Development files:
/opt/csw/include/foo/1.0/foo.h
/opt/csw/lib/foo/1.0/libfoo.so
/opt/csw/lib/foo/1.0/sparcv9/libfoo.so
Shared files:
/opt/csw/share/foo/1.0/...
Compatibility symlinks:
Handled by alternatives.
/opt/csw/bin/fooapp → foo/1.0/fooapp
/opt/csw/include/foo.h → foo/1.0/foo.h
/opt/csw/lib/libfoo.so → foo/1.0/libfoo.so