Какой документации не хватает для эффективного и комфортного использования Calculate Linux?

Ого! Вижу - наболело))) Как и у меня, впрочем, и думаю, у очень многих.
Однако эта простая мысль очень трудна в практической реализации - сделать хорошую документацию (плюс поддерживать её в актуальном состоянии) - задача по трудоёмкости соизмеримая с собственно изготовлением софта. А так как мы находимся в зоне бесплатного ПО - у разработчиков элементарно не хватает рук на эту работу. Ну то есть между написать нормальные доки или прикрутить пару фич / исправить пару багов они выбирают второе (что, кстати, не всегда правильно). Кроме того софт взаимоувязан, и дополнительно постоянно есть задача актуализации в связи с развитием сопряжённых частей ПО. Как у Алисы - чтобы оставаться на месте, нужно бежать изо всех сил (Я был разработчиком софта в прошлой жизни и поэтому знаю всё это не понаслышке).
С другой стороны - да, разработчики, как правило, очень сильно недооценивают важность хорошего документирования своих продуктов - им-то всё понятно))) Я время от времени налетаю на какую-нибудь программу, про которую вообще не могу понять, что она делает и зачем её написали, даже после курения хелпов/манов. Или назначение программы с трудом восстанавливается из описания ключей, что само по себе близко к бессмыслице, согласитесь. Добрая половина опций ядра не документирована вообще никак - даже гугл не в курсе дела( И это наша сегодняшняя реальность - и вряд ли она изменится в обозримом будущем. А хотелось бы - от этого напрямую зависит количество пользователей дагного конкретного софта (дистрибутива). Чем ниже порог вхождения - тем больше людей его преодолеют - тем больше появится возможностей для его развития ( в т.ч. для финансирования разработок) - тем больше станет пользователей - и спираль начнёт раскручиваться. А пока в зоне генту скорее наоборот - схлопывание - многие пакеты выкидываются из портеджа из-за нехватки майнтейнеров. Кальку я чуть не бросил сам, проблуждав несколько недель в заветных трёх соснах (портеджи, USE-флаги, шаблоны). Кстати, последняя сосна так и не поддалась…
Хотя казалось бы - я уже повидал всяких юниксов-линуксов и тривиальная смена дистрибутива не должна была быть столь трудозатратной. На сегодняшний день мне явно дешевле перейти на чистую генту и забыть про шаблоны (ибо встроенный в систему непонятый инструмент хуже его отсутствия, т.к. дополнительно увеличивает энтропию). К счастью, разработчики кальки в курсе проблемы и по-видимому, собираются её решать.

+1
но знаете, действительно все не так плохо. cld шикарен тем, что его можно просто взять и использовать.
Нужно просто еще чуть-чуть понятно написанного и + немного примеров в тех случаях, когда решения нестандартны и редки.

В статье Переменные шаблонов
Не описана переменная ac_install_live. с какой версии шаблонов она доступна (в проэкте ведь используются несколько версий утилит) в каких ситуациях это событие происходит.

Вообще - неплохо было бы при добавлении удалении каких либо фитч, описывать их в ChangeLog-е

Времени это занимает гораздо меньше, зато может служить если не заменой хаутушки, то хотбы костяком для ее написания.

И не предлагайте читать комменты к коммитам.
Во первых - лично я пока не лучшим образом работаю с git.
А во вторых - это просто неудобно. Для просмотра небольшого описания что куда зачем добавилось - надо копировать к себе всю историю проэкта.

Скоро перейдём на 3.1, там в основе будут событийные переменные. Я думаю мы будем их описывать комментариями непосредственно в шаблонах.

P.S. Спасибо всем за предложения. Будем систематизировать и потихоньку разгребать. Сейчас важно выпустить 3.1 версию утилит, в ней произойдут важные изменения в структуре шаблонов и схеме работы.

Спасибо за вашу работу.