> У меня есть очень живой кейс. Моя система грузится в initrd, который
> я, кстати, могу генерить динамически, а /usr монтируется с диска.

С таким же успехом можно генерить initrd динамически и с "merged usr". Большая часть дистров так и делает сто лет: на автомате хуком после инсталла кернела в пакетнике генерят ему в пару initrd с ТЕМИ модулями ядра. Так что ваш "хайтек" давно уже "попсовый ширпотреб", так даже убунта умеет. А основная система монтируется... да в общем откуда угодно, к initrd это мало отношения имеет в общем случае. По нормальному они декорелированы и пересекаются только тем фактом что модули и некоторые программы (e.g. busybox) в initrd взяты из вон того ядра.

> Иногда не монтируется, потому что нет драйверов для контроллера или ещё какой-нибудь
> железяки, на которой я гружу эту систему, но у меня всегда
> есть рабочий initrd с инструментами для рекавери, поиска дров, и так далее.

Основную систему вообще не обязано интересовать что там в initrd, а initrd в принципе может запустить что угодно, структурированное как угодно. Соответственно никаких минусов у вон того решения - нет. Для инитрд вообще есть механизм pivot root - можно весь рутфс свичнуть. И кстати ничему не противоречит если initrd будет тоже "merged usr" по структуре.

И более того - завязка initrd на структуру системы, или системы на структуру initrd делает это хрупким и кривым решением.

> Система никогда не делает chroot, у неё корень всегда на initrd, и
> она продолжает работать даже если диск сдох.

Если диск сдох, initrd с него тоже не прочитается? А если initrd все же читается - ну ок, с нем и будем тусоваться. И _его_ тулсах. Ведь уповать на систему на дохлом диске в рекавери не было частью плана, так? :) Да и не понятно что вы делать намерены в инитрд если "диск сдох".

> То же самое можно сделать с /usr на NFS, когда "затравочный" образ
> запускается по сети, или с флешки на тонком клиенте.

В линукс есть множество вариантов как и что делать, "merged usr" уж точно не делает подобные вещи "нерешаемыми".