Необзяательная зависимость

Зависит от конкретного приложения. Может быть как ты сказал. И не обязательно библиотека. Может быть исполняемый файл. Например, Ark использует бинарники 7zip, zip, rar и т. д. для работы с архивами. Если какого-то бинарника нет, то этот тип архива просто не будет поддерживаться, однако другие будут открываться как обычно.

Есть и иной вариант - программа может поддерживать плагины. Например, есть Firefox. Он ничего не знает про AdBlock, но при старте грузит все плагины из определённого каталога. И есть пакет adblock, который кладёт это расширение в нужное место, чтобы Firefox его увидел.

То есть варианта два: в программе есть поддержка некоторого функционала, но основная реализация находится в другом файле, при этом программа написана по-умному и не падает от отсутствия этого файла, а пишет ошибку или просто скрывает нужный пункт меню. Или же программа ничего не знает про дополнительный функционал, но поддерживает плагины, которые могут делать что-угодно. А некоторые популярные плагины попали в репозитории.

Также опциональная зависимость может быть вообще файлом данных. Например, для среды проектирования печатных плат KiCad есть пакеты с дополнительными библиотеками компонентов.

и не падает от отсутствия этого файла, а пишет ошибку или просто скрывает нужный пункт меню.

Каким образом могут общаться 2 программы? На примере уведомлений кед, которые при наличии программы для озвучки речи будет использовать ее возможности. Я знаю только два варианта: через текстовые файлы и через dbus. О втором мне плохого тут наговорили - тот еще тормоз.

но поддерживает плагины, которые могут делать что-угодно.

Тут либо свой велосипед интерпретатор или встраиваемые языки вроде lua?

Ну тот же Ark запускает свои бекэнды с нужными параметрами командной строки и слушает результат, который они выводят на stdin. В случае синтезатора речи вполне может быть команда типа «qt5-say-string Привет, мир!» и DE будет просто вызывать её в нужный момент. В случае синтезатора речи этого вполне достаточно. Хотя может быть и библиотека, подгружаемая динамически, если она есть.

Тут либо свой велосипед интерпретатор или встраиваемые языки вроде lua?

Вовсе не обязательно. Плагины вполне могут быть нативными библиотеками. Скажем, плагин это so-библиотека, которая экспортирует некий стандартный набор функций. Все плагины лежат в /usr/lib/my-cool-applicaiton/plugins. При запуске приложение загружает все so-файлы оттуда. Если плагины на интерпретируемом языке, то это совсем не обязательно Lua - может быть JavaScript или Python. При том само приложение может быть на этом же языке и подгружать дополнительные модули стандартными средствами (например, приложение на Python может импортировать все модули из определённого каталога).

С бинариком можно через пайп, а с библиотекой - через позднее связывание.

Есть ли какой-нибудь оверхед при дроблении библиотек на мелкие куски?

Что можешь сказать о производительности dbus и будущего kdbus? По-твоему, когда последний будет стандартизирован? Какого обмениваться через него по 5МБ? А kdbus?

Ничего. Но могу сказать одно точно - если надо обмениваться по 5МБ, то с архитектурой ПО что-то не так.

Идея про плагины-библиотеки понравилась, получается их можно будет на любом яп писать? А как же будет реализовано взаимодействие с основной программой, ведь программа же рулит всеми делами, а как она будет рулить, если не будет знать названия классов? Как библиотека может всттроить свой функционал в программу?

DBus не создан для скоростного обмена многомегабайтными сообщениями. Он нужен для обмена короткими сообщениями между приложениями. Когда нужна скорость используются пайпы, общие регионы памяти и т. д.

В каждой библиотеке, например, может быть одноимённая функция GetPluginInfo, которая будет возвращать стандартизированную структуру, описывающую все классы и зачем они нужны. Основная программа будет подгружать библиотеку, получать адрес этой функции, вызывать её, запоминать подробную информацию о плагине, продолжать грузить плагины дальше.

Можно ли будет написать такой плагин-библиотеку на питоне или баше?

Если библиотека является so-файлом, то нет. Хотя можно сделать библиотеку-обёртку на компилируемом языке, которая уже будет вызывать функции нужного языка.

Если плагин является исполняемым файлом, с которым общаются через аргументы командной строки и stdin/stdout, то его можно будет писать на любом языке вообще.

1. Интересная идея у stdin и stdout, а я могу подключиться к другой вполне самостоятельно работающей программеА, послать ей по stdin информацию на обработку, а потом по stdout получать результат, а потом просто отсоединяюсь от нее? Если да, то можно делать это одновременно с другой программойБ, уже работающей по std с программойА?
2. А может можно программуА, работающую через std, сделать сервисом в systemd? 3. Накладно ли будет дергать с жесткого диска программуА каждые 2 секунды (ls, grep), нежели работой через библиотеку?