Por que existem `/lib` e `/lib64`, mas apenas `/bin`?

Primeiro, por que existem separados /libe /lib64:

O Filesystem Hierarchy Standard menciona que separam /libe /lib64existem porque:

10.1. Pode haver uma ou mais variantes do diretório /lib em sistemas que suportam mais de um formato binário que requer bibliotecas separadas. (...) Isso é comumente usado para suporte de 64 bits ou 32 bits em sistemas que oferecem suporte a vários formatos binários, mas requerem bibliotecas com o mesmo nome. Nesse caso, /lib32 e /lib64 podem ser os diretórios da biblioteca e /lib um link simbólico para um deles.

No meu Slackware 14.2, por exemplo, existem diretórios /libe /lib64 para bibliotecas de 32 bits e 64 bits, respectivamente, embora /libnão seja um link simbólico como o trecho FHS sugere:

$ ls -l /lib/libc.so.6
lrwxrwxrwx 1 root root 12 Aug 11  2016 /lib/libc.so.6 -> libc-2.23.so
$ ls -l /lib64/libc.so.6
lrwxrwxrwx 1 root root 12 Aug 11  2016 /lib64/libc.so.6 -> libc-2.23.so

Existem duas libc.so.6bibliotecas em /libe /lib64.

Cada binário ELF construído dinamicamente contém um caminho codificado para o interpretador, neste caso /lib/ld-linux.so.2ou /lib64/ld-linux-x86-64.so.2:

$ file main
main: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, not stripped
$ readelf  -a main  | grep 'Requesting program interpreter'
      [Requesting program interpreter: /lib/ld-linux.so.2]

$ file ./main64
./main64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped
$ readelf  -a main64  | grep 'Requesting program interpreter'
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

O trabalho do interpretador é carregar as bibliotecas compartilhadas necessárias. Você pode perguntar a um interpretador GNU quais bibliotecas ele carregaria sem nem mesmo executar um binário usando LD_TRACE_LOADED_OBJECTS=1ou um lddwrapper:

$ LD_TRACE_LOADED_OBJECTS=1 ./main
        linux-gate.so.1 (0xf77a9000)
        libc.so.6 => /lib/libc.so.6 (0xf760e000)
        /lib/ld-linux.so.2 (0xf77aa000)
$ LD_TRACE_LOADED_OBJECTS=1 ./main64
        linux-vdso.so.1 (0x00007ffd535b3000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f56830b3000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f568347c000)

Como você pode ver, um determinado interpretador sabe exatamente onde procurar por bibliotecas - a versão de 32 bits procura por bibliotecas /libe a versão de 64 bits procura por bibliotecas em /lib64.

O padrão FHS diz o seguinte sobre /bin:

/bin contém comandos que podem ser usados ​​tanto pelo administrador do sistema quanto pelos usuários, mas que são necessários quando nenhum outro sistema de arquivos está montado (por exemplo, no modo de usuário único). Também pode conter comandos que são usados ​​indiretamente por scripts.

IMO, a razão pela qual não há separação é que /bin, /bin64se tivéssemos o arquivo com o mesmo nome em ambos os diretórios, não poderíamos chamar um deles indiretamente porque teríamos que colocar /binou /bin64primeiro em $PATH.

No entanto, observe que o acima é apenas a convenção - o kernel do Linux realmente não se importa se você tiver /binarquivos /bin64. Se desejar, você pode criá-los e configurar seu sistema de acordo.

Você também mencionou o Android - observe que, exceto por executar um kernel Linux modificado, não tem nada a ver com sistemas GNU, como o Ubuntu - sem glibc, sem bash (por padrão, é claro que você pode compilar e implantar manualmente) e também estrutura de diretório é completamente diferente.

A razão é que os diretórios lib/lib64 podem conter arquivos que possuem o mesmo nome porque são bibliotecas compartilhadas com diversos programas. Colocá-los em diretórios separados resolve o conflito. Não há (geralmente...) uma boa razão para distribuir executáveis ​​com o mesmo nome no mesmo sistema que são de 32/64 bits, mas como pode haver uma mistura de executáveis, as bibliotecas compartilhadas devem ser fornecidas.