А мне нравится, ну почти. По крайней мере идея нормальная. Длинный имена каталогов с большой буквы это конечно явный баг :).

Не вижу чем переход к такой структуре помешает разделить пользовательское и системное ПО, только легче станет. Для восстановления системы гораздо лучше IMHO использовать рам-диск. Разделение доступа, опять же по-моему скромному мнению, лучше поручить системам а-ля AppArmor и другим подобного типа определяющим правила доступа по пути, кстати при переходе к подобной структуре правила должны стать заметно проще, ведь достаточно описать права одной директории и наследовать их для всех дочерних объектов, нежели описывать права для каждого (важного) файла пакета.

И мейнтейнерам жить должно стать легче (хотя Михаилу виднее), ведь по-сути стандарт не описывает (IMHO) досконально структуру ФС,  а соответственно расположение файлов программ различается от дистриба к дистрибу, причем иногда существенно. При этом соответственно каждый мейнтейнер взяв от мейнстрима исходники занимается составлением/переписыванием правил определяющих где и что должно лежать, т.е. строит/переделывает "велосипед" (в некотором смысле).

Внутри директории программы очевидно стоит оставить все как есть, т.е. обычное юникс-дерево.

Единственное, что меня напрягает, решение в виде триллиона ссылок (хотя сейчас из-за обратной совмстимости этого наверное не избежать). Вопрос с вызовом бинарников и т.д., мне кажется (по крайней мере относительно исполняемых файлов) это должно решаться на уровне ФС, в ней все равно храняться все биты доступа. Нужно просто сделать хранилища, кеши, со списком исполняемых файлов, суид и т.д. И внести изменения в системные вызовы типа exec, которые будут искать по кешу если вызов сделан по относительному пути. Обновление кеша может происходить как по-требованию, так и автоматически при chmod.
По сложности IMHO это не превысит текущего решения с симлинками, но будет красивее.

Кстати парочку симлинков при желании никто не мешает.