иногда лучше сначала исследовать проблему и обсудить варианты решения

Написание кода, или хоть какое-то движение в сторону эксперимента - это и есть исследование. Что тут обсуждать,  тут даже задача толком не поставлена. Пока человек не прояснит для себя, что он хочет сделать, это будут просто домыслы, которые непонятны другим

Да даже расписать, что там за дуальность, и к чему она дуальна, будет полезнее

И да, билд системы сложны именно потому, что сложны языки и окружения, а не потому что разработчики не смогли лучше

Чтобы подобные задачи решать, нужно пойти и поработать с парой-другой билд систем

В том числе с плюсовыми, когда стоит задача сбилдить проект с зависимостями под разные ОС и платформы

Это сразу снимет массу вопросов и покажет, какие из изначальных предположений неверны

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

UPD и еще не забыть про дебаг/релиз, а также условную сборку

Очень много вопросов отпадет, и тогда станет ясно, что тот подход, который у человека в уме (не оформившийся толком), может что-то и решает, но уж точно не глобальную задачу "как все радикально упростить". Упростить если удастся, то лишь небольшую часть проблемы билд систем, в рамках узких и не охватывающих наиболее проблемные места. Потому что проблема здесь не в accidental complexity, которую можно как-то уменьшить выбором иных подходов. Проблема в essential complexity предметной области. И вот хотя бы этот факт нужно осознать и четко поставить задачу: мы хотим что-то улучшить маленькое, и понимаем, что именно и как

ложная дихотомия

При этом, конечно, accidental complexity разных билд систем разная. make и autotools - это кошмар из кошмаров. CMake - ни туда, ни сюда, а скорее даже плохо. QBT - достаточно удобно, декларативно. QMake - идейно похоже на make. А есть еще мета-билд системы вроде gyp (generete your project), и самих форматов проектов тоже куча для С++: CMake lists, MSVS, парочка форматов для Qt. С++ - самый плохой в этом смысле язык, но и самый показательный. В современных языках всё лучше, там хотя бы не такой зоопарк. Но даже в Haskell две системы сборки и три системы описания проектов. А уж собрать JS проект - это надо быть сильным духом

(Да и у самой Вижуал Студии для С++ было несколько существенно разных способов описать и сбилдить проект)

Наименьшую accidental complexity из всех систем имеют те, где проект/сборка описываются декларативно, на специальных DSL / eDSL. Тот же hpack в Хаскеле

Декларативный gyp для С++ тоже шаг вперед, но его уже давно перестали поддерживать.

Короч, тема куда глубже, чем кажется на первый или второй взгляд

Зооопарк способов конструирования дев. окружений неавжен, если типизировать их, по построению, "пригодностью для класса проектов"

А билд продакшена - вовсе аут от скоп

Типизировать можно. Я могу себе представить описание проекта или билд-скрипта на статически типизированном языке. Это поможет, но вряд ли значительно. Некоторые системы и так делают проверки, что там элементы билд-языка использованы правильно

Я вас не понимаю. Что значит - их типизировать? Присвоить им тайп-левел метки аки фантомные типы?

Вам уже сейчас ничего не мешает писать билд-скрипты на том же Haskell. Можно в системе типов декларативно описать, как должен происходить билд. При вынесении дополнительной логики на уровень типов можно даже добиться, чтобы для дебаг-билда нельзя было задать включение оптимизаций. Но это не решит основных проблем, вам все еще надо будет описывать, как доставать и билдить зависимости, как это все раскладывать по папкам, с камими опциями вызывать компилятор. Можно описать опции компилятора на более-менее типизированном eDSL и сделать так, чтобы только правильное их сочетание можно было указывать в самом скрипте, но всё равно остается потребность их указывать