вибачаюсь. дійсно дурня
Як я зрозумів ви пропонуєте створити модуль наприклад для fuse який буде перетворювати конфігурацію що зберігається наприклад в ldap в віртуальний файл для програми (наприклад cups).
Можна й так. Каталоги /proc та /sys - гарний приклад такої системи конфігурації (поцупленої з Plan9). Тобто можна взяти якусь базову файлову систему, туди скопіювати /etc, зверху наліпити unionfs і зверху накласти якийсь аналог /proc, який буде перекривати певні вказані файли з /etc та дозволяти змінювати їх на льоту через якесь API, дружнє до утиліт. Непогана тема для дипломної роботи. :-)
Але я робив узагальнення трошки вищого рівня - якщо у вас тільки дві сутності, то все стає значно простіше, так як є тільки один зв’язок - пргограма <-> файлова система. Якщо додавати нові сутності (бібліотеки, демони, мережі, etc.), то складність системи (кількість зв’язків між компонентами) росте по O(n!), де n - кількість компонентів.
Якщо у вас тільки програма і ФС, то n! - 2. Якщо у вас програма, ФС, бібліотека, демон/БД, мережа, то n! - 120. У першої системи значно кращий потенціал для росту - до 60-ти раз. :-)
Я бачу 2 проблеми (тільки я зовсім не розбираюсь в будові фс - тож не бийте сильно 
):
1. надійність - якщо станеться якась помилка, то вона відіб'ється на всіх програмах що користуються цією фс. Якщо ж помилка станеться в бібліотеці - то постраждає тільки один програма.
...то постраждають всі програми, які користуються цією бібліотекою.
2. доведеться написати якісь бакенди для кожного типу|виду файлів|конфігів.
Точно так само як і з бібліотекою. Але у випадку бібліотеки, доведеться правити також і програми, які ними користуються.
До тож проблема зворотнього завантаження - наприклад при встановленні.
Я не знаю що таке зворотнє завантаження (розвантаження?).
Я думаю це непоганий варіант для закритих програм, або для таких, модифікація яких небажана чи неможлива.
Угу. При чому таких програм переважна більшість.
