Унификация - есть идея. Нужны комменты.

Юмор дело хороше, но пожалуй в менее агрессивной форме.
unionfs - вот это точно костыль:
Отцените прозачность следующего текста:

Unionfs also supports rename in DELETE_ALL mode. Using the notation of Section 3.5, the procedure for rename in DELETE_ALL mode is as follows: 
1 union_rename(S,D) { 2 for i = RS downto LS { 3 if (i != LD S[i] exists) 4 rename(S[i], D[i]) 5 } 6 for i = LS - 1 downto LD + 1 7 unlink(D[i]) 8 if (S[LD] exists) 9 rename(S[LD], D[LD]); 10 else if (LD < LS) 11 unlink(D[LD]) 12 }

взято от сюда http://www.am-utils.org/docs/unionfs-tos/unionfs.html
что касается быстродейтсвия - достаточно взглянуть на следующую схему http://www.am-utils.org/docs/unionfs-tos/figures/stacking_fanout.png, что отбросить всякие кривотолки.

libexpat - гугл поможет.

"Если вы не в курсе, портеж не сваливает все ebuildы в одну папку, а какраз распределяет их по древовидной стрктуре." - а то я первый раз в жизни вижу gentoo, мля читать надо внимательно, я ниразу не утверждал "сваливает все ebuildы в одну папку", так же как и не предлагаю все программы сваливать в одну дирректорию.

"Правильно, чтобы небыло вендоподобного - каждая служба хранит свой скрипт в своей /Program files/Program name/... тьфу - даже писать такие пути противно! :-(" - Чё вы чушь городите. В винде зачастую конфигурации служб, да и программ, хранятся в реестре.

"В том, что разработчики отдельных пакетов из*бываются, нет ничего хорошего. Согласен. Но причем здесь ваше предложение? :-)" - при том что вы нифига не поняли что я предлагаю, иначе не сравнивали бы так ""индивидуально унифицируется" - эквивалент "синенькое белеется"".

Во фразе - 2) унифицируются место положение файлов каждой программы индивидуально - слова "индивидуально" и "унифицируется", выдранные вами из контекста и неверно истолкованные, имеют следующей смысл:
Унификация - приведение к единообразному распределению файлов и каталого программы по дереву системы.
Индивидуально - применительно к каждому экземпляру программы.

Перечитать разов 10 на ночь может дойдёт 8)

По сути я предлагаю нахер убрать ручное именование директорий по которым распределяется программа, пусть это делается автоматом, на уникально основе. А userlike представление реализуется файлом описания лежащим в дирректории. Косвенный аналог можно подсмотреть в DNS - установление соответствия ip<->имя

Без намеков, пожалуйста.
Не можете толком объяснить, почему от вашего предложения "жить на Руси хорошо станет", не надо было начинать.

Может хватит уже бросаться фразами типа

а по-русски объяснить, ЗАЧЕМ ЭТО НУЖНО?

А Вы взгляние на это дело под другим ракурсом:
а) Возможно отказаться от создания и указания каталога установки (то, что --prefix, можно задать глобально мне известно)? Если я захочу установить рядом ещё один экземпляр программы, опять создавать каталог, менять префикс?
б) Насколько остаёмся в рамках концепции файловой системы, описываемой POSIX, создавая /usr/local/programs/Xorg-7.1/ ?

В варианте который я предлагаю:
а) Возможно полностью отказаться, при установке/обновлении, от ручного создания каталогов и задания префикса.
б) файлы и каталоги располагаются строго по предписываемым POSIX правилам размешения.

Кроме того можно например перед установкой, создавать каталоги для программы автоматом, сразу устанавливая на неё права и создавая для неё пользователя, например с тем же самым идентификатором appdomen, тогда можно ещё и усилить безопастность при установке программы, локализуя работу установщика в пределах созданых директорий (заранее -пугать chroot, sandbox меня не надо, пуганые уже), и не применяя рутовые права, тут коненшно ещё много нюансов, но в целом надеюсь мысль ясна.

Пример, на основе сказанного, - Человек устанавливает Xorg 7.1, в то время как в системе есть Xorg 6.9 (не будем вдаваться в то, как они будут разделять видеокарту при совместном запуске, это сейчас не важно):

у. (Установщик) - Ось? Есть в системе Xorg? 
о. (ось) - Есть, вот его id(appdomen), вот его имя(Xorg-6.9) 
у. Человек? В системе уже есть Xorg-6.9 c id(appdomen) таким-то, что будем делать? Обновлять/Ставить рядом/или Тормознёмся?
ч. (Человек) - Ставить рядом.
y. - Ось? Человек сказал будем ставить рядом.
о. - Ну тогда держи новый id(appdomen), и вот тебе права на втыкание своей лабуды, скажешь когда закончишь.
у. - Ок.
...

"Во первых"
- Не факт, мне очень часто встречаются программы которые имеют упаковку под разные дистры и сделаны упаковки именно программистами программы, например mysql други примеров тоже валом. Это поначалу когда дитрибутив набирает обороты, в основном программы адаптируют дистостроители, если проэкт становится популярным, то програмисты сами начинают адаптировать стои программу уже сразу "из коробки".

"Но какое это имеет отношение к вашей идее?"
- Так! Надо же! Она всё таки моя, что это с вами? Вы забыли что это плагиат? Перечитайте весь топик, поробуйте взвесить, оценить сопоставить. И может тогда до вас дойдёт "отношение" и вы перестанете разводить демагогию.
А пока что бы было яснее что из себя представяет унифицированный подход, на примере конфигов:
есть Пользователь Продвинутый (ПП), админ например:
ПП купил новую видеокарту и хочет поиграть с доп. ф-циями:
# vim xorg-7.1/etc/conf
у ПП установлен apache, он решил добавить виртуальные хосты:

# vim apache-2.1/etc/conf
# apache-2.1/init/restart

также установлен mysql, ПП вдруг пондобилось поменять местоположение баз, на отдельный RAID переместил:

# mysql-5.2/init/stop
# mv mysql-5.2/var/data/* /mnt/raid10/mysql/data/
# vim mysql-5.2/etc/conf
# mysql-5.2/init/start

Это не проще чем используемый сейчас подход? Надо ещё что-то объяснять?

"Прикиньте какой код и где надо написать чтобы всё это выглядело так как Вы хотите."
- Ну прикинул, а что Вы хотели этим хотите сказать? Да схема в реализации не проста, это и так ясно.
1) скрипт который генерит app-id, заносит его в файл, создаёт каталоги, ставит права на них, устанавливает соответствие в реестр-файле;
2) скрипт который проводит обновление локального репозитария или только вспомогательного реестр-файла;
3) скрипт инициализации операций install/reinstall/delete/update/check/fetch/depence и других для устанавливаемых/установленных пакетов;
4) имплементация в шел, которая будет оверрайдить/релоцировать прямой путь описаловом из реестр-файла и файлов дескрипшинов из директорий программы.
...
N) ...., где N пока не определено.
Но всё это ходя из пункта 4) скрыто, и глаза пользователю не мозолит без надобности, ниже приведу пример.

"рекомендую посмотреть на KDE"
- KDE на мой взгляд несмотря на всю его мощь достаточно противоречивый комплекс, со множеством подходов которые не были правильными изначально. Пример - следования идеалогии кнопки "пуск" и списка программ аля microsoft - первый из не правильных подходов который применили в KDE, точнее неправильность выражается в ограничении ф-ционала управления, постулатами предложеными ms, а ранее nextstep, при этом конешно осталась консоль которая как раз и заменила тот самый скоростной доступ по фильтру. Ещё при первом опыте использования win95, мне стало не понятно - почему нет возможности использовать фильтр для установленных программ, я в каждой версии windows ожидал увидеть нормальный способ доступа к установленным программам, но наиболее правильный подход увидел только в бетке vista'ы. Точно так же я недоумевал почему в KDE, а потом и в Gnome (при том что кол-во программ установленных в типичном linux в разы больше чем в windows), до сих пор нет нормальных гуй средств навигации по установелнному ПО. И только сейчас в KDE 4 наконец появился фильтр, причём после появления оного в windows, только сейчас в Gnome начали осознавать что концепция предлагаемая ms не есть самая верная, начали тотальную конверсию gnome-panel, кажется gimmie зовётся.

"И опять мимо!..."
- Знаю я что в nix на порядок больше пакетов обычно стоит - и тем паче нужна более унифицирующая система, чем та, что существует сейчас.

"На счёт побуждения и НЕПОЛОЖЕНО Вы видимо не поняли ... Для того, чтобы Ваша система принесла ему пользу, Вам надо сделать чтобы ему было удобно. Как это сделать просто в рамках Ваше модели я не вижу, а вижу дополнительные программы и сложности..."
- Вот как раз Вы меня и не поняли, равно как и другие. Я говорю о всём том же самом. Просто я предположил что люди которые пользуют gentoo, являются менее законсервированными в рамках различных идеологий, и потому думал, что сходу сумеют развить идею и оценить плюсы предлагаемой концепции. Но видать я ошибся. Gentoo'шникам так же как и другим людям очень трудно абстрагироваться от привычных вещей (ИМХО). Потому приведу другой пример, который не давно привёл на nclug.ru:
Развивая идею:
Можно определить список всевозможного программного обеспечения, и установить статус локально -[не]установлен в файле-реестра, типа:

bind-9.3.2 {1233-434a-111c-a124} 
wget-1.10.2 {} 
samba-3.0.23a {} 
xorg-7.1 {77b3-4f76-1c01-1a24}

соотвественно, пустые {} (их может и вообще не существовать) указывают на состояние НЕ Установлен.
т.е. набрав
samba<tab> дорисуем -3.0.23a
а строкой ниже увидим samba-3.0.23a {not installed}
жмякним выбираем действия

You have next commands to manipulate with samba-3.0.23a 
ask(a) - ...
depends(d) - list all direct dependencies 
check(c) - ... 
install(i) - ... 
fetch(f) - ... 
pretend(p) - ... 
... 
other commands 
...
wait for command: 

хотим обновить/удалить? Тоже самое жмякаем
samba-3.0.23a<enter>
и нам на выбор варианты
Do you want samba-3.0.23a to reinstall|update|delete|cancel? [r|u|d|c]

Если нам надо без вопросов ставить, то можно например предусмотреть
samba-3.0.23a --help
и среди всего списка команд добавить
--silent(s) или --quiet(q)
да и --help можно задвинуть, все опции по enter'у светить.

т.е. имеем для продвинутого пользователя:
samba<tab>-3.0.23a -qi
для новичка можно и gui нарисовать, причём можно вполне обойтись dialog/Xdialog

Это, на Ваш взгляд, сложнее чем emerge samba ?

Кроме того можно ставить пакет который никогда не был в репозитории, но который подчинен общим правилам, с тем лишь нюансом, что зависмости описаны в самом пакете (что можно и нужно взять за правило для всех пакетов вообще). Это в пику того что не продвинутому пользователю, например всё той же gentoo, совсем не обязательно ждать очередного ebuild'a для его любимой программы которую он обновляет чаще чем ментейнеры репозитария.

"На счёт субд"
- Разве я с этим спорю? Да СУБД расширяет возможности, но при этом ещё усложняет и делает более уязвимой систему к сбоям, поэтому в данном случае можно обойтись без СУБД, и если это "можно" не есть значительно сложнее чем реализация на СУБД, на мой взгляд, нужно обойтись без CУБД.