Why are boost package libs installed to /usr/lib/x86_64-linux-gnu?

The library packages have been made multiarch, meaning that you can simultaneously install both the amd64 version and the i386 version on an amd64 computer. If you want to install the i386 version of a library, suffix the package name with :i386. (For example, sudo apt-get install libboost-system1.54.0:i386)

Library packages are shifting towards becoming multiarch, so that it is a little easier to install packages from other architectures and run programs compiled for other architectures.

This is by spec. The headers are still an unresolved issue in the spec. and considered out of scope as noted in the source under the heading of Unresolved Issues

"Design

Filesystem layout

In order to seamlessly accommodate more than one ELF ABI on a system, the library for each (soname,ABI) pair must have a unique path on the filesystem. The FHS attempts to address this for the amd64 case by requiring that /usr/lib be reserved for 32-bit libraries, with 64-bit libraries located in /usr/lib64. This design has a number of shortcomings:

This is not forwards-compatible with any future ABI changes, which would require further design work and further modification of packages to handle the addition of new paths. (Indeed, this is already a concern for the MIPS architecture which has three distinct ABIs in use in parallel.)

The amd64 architecture must be special-cased in the library packaging, as the only architecture that uses /usr/lib64 instead of /usr/lib. (Two pre-existing 64-bit Linux ports, Alpha and IA-64, also used /usr/lib for their 64-bit libs.) This is unnecessary added complexity.

It does not address emulation use cases, such as qemu, which could integrate much better and more efficiently with the system if the packages for a qemu arch were co-installable.

The current design used by Debian and Ubuntu also fails on a key point where the FHS layout does not:

The path for x86 and x86-64 libraries varies depending on whether the system is natively 32-bit or 64-bit, so translating paths at install time is insufficient for the general case because some libraries need to embed plugin paths in the binaries themselves.

Multiarch seeks to address all of these issues, at the expense of a one-time transition, by migrating libraries to subdirectories that include the architecture triplet as part of the path:

/lib/i386-linux-gnu /lib/x86_64-linux-gnu /usr/lib/i386-linux-gnu /usr/lib/x86_64-linux-gnu"

source