> Make -> ninja

I would disagree on that one. Ninja config might not be turing complete, but they're generated by turing-complete tools (usually cmake). Nobody writes ninja by hand, thus I would argue it's irrelevant!

Python went from setup.py to pyproject.toml, but pyproject.toml declares a build-system, which is another package which all the complex logic from setup.py.

Granted, it's a "simpler" config syntax, but the total system complexity has not decreased.

> Python setup.py -> pyproject.toml?

That's because setup.py was objectively a mistake. In order to know how to run the package you need to know its dependencies, which requires evaluating setup.py, but you cannot evaluate setup.py until you know the dependencies, which requires you to evaluate setup.py, and so on. The pyproject.toml is plain text where you specify the build backend and its options, and the build system can be as complex of a program as need by.

If anything, pyproject.toml is an example of taking the idea of programmable configuration to its next conclusion. The build system is part of the configuration and it's more than a simple script, it's an entire application. You just plug in its name into the universal entry point pyproject.toml.

I'll die on the hill that Helm charts are more of a problem because text/templating is a weird looking templating language then anything else.