That's just a start. Tup is much less flexible and forces certain conventions on the build system. It is also much more rigid about introducing dependencies during the build.

> but the problem in moving to a better build system is that makefiles are so convoluted and hard to reason about

Nowadays Makefiles are largely autogenerated by the build system. How many people are actually editing makefiles by hand in non-pet projects?

> How many people are actually editing makefiles by hand in non-pet projects?

people that don't want makefiles so convoluted and hard to reason about that they can't edit them by hand..

i suggest taking a look at any of the BSD build systems and seeing what sane use of make can look like (PMake and not GNUMake; imho PMake's language makes this doable; GNUMake's language makes autotools and other mess-generating 'helpers' required)

    http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/share/mk/bsd.prog.mk
    https://svnweb.freebsd.org/base/stable/12/share/mk/

> people that don't want makefiles so convoluted and hard to reason about that they can't edit them by hand..

You've missed the point. The point was that nowadays editing or even looking at a makefile is far from standard practice, because makefiles are autogenerated by the build system and are closer to temp files than to project files.

Who wastes their time reasoning about a temp file that just works?

I wrote a build system for an embedded system with two processors and lots of code sharing across three platforms in Make because no other tool would let me program the whole DAG in the same language. The makefiles generated themselves.

Pond meet frog