Про типы данных и конфиги я для себя решил, что это ничем не отличается от входящих параметров web-API вызова от клиента. И работать с этим надо точно так же:
- надо в коде описать схему параметров для каждого отдельного приложения в проекте;
- схема определяет типы данных, ограничения, валидацию, дефолтные значения, хелп-тексты и всё остальное, что можно описать в разных реализациях схем/десериализаторах;
- пишется "бекенд", который читает конфиг от куда либо: ini, yaml, xml, json или из базы данных и применяет к ним схемы для десериализации и валидации. Это почти полностью решает проблему с типами - если в схеме требуется строка, то десериализатор вернёт всегда строку, даже если ему подсунули число.
- по красоте можно написать генератор документации, который по схемам сгенерит доку для конфига (в схеме есть уже всё, даже хелп-тексты).
- ещё более крутая красота - автоматом генерить админку для конфига на основе схем. Это полезно когда конфиги лежат в базе, хотя и редактировать файлы админкой, никто не мешает.

Может кто видел dconf в линуксах. Там как мне кажется подобная штука - GUI редактор явно от куда-то берёт схемы для настроек где есть всё и описание и типы и всё остальное.

а чём проблема? Админы постоянно не правильно конфиги делают?

И забыть как страшный сон редактирование текстовых конфигов через ssh

конфиги обязаны быть в git е и автоматически расскатываться. Да инсталяционные конфиги не должны лежать рядом с кодом, ибо там пароли от базы данных лежат, наприме. Но в любом случае конфиг это часть инсталяции и никаких ручных модификаций быть не должно.