Maybe it would be possible to make autotools not-crappy by adopting a similar strategy as with cmake:
1) treat configure.ac as the definition of project's compiling rules, like the CMakeList.txt file;
2) compiling system uses this new utility, let's call it "fastconf", to read configure.ac and directly generates Makefile without ever invoking shell, m4, or generating any other files;
3) all compiling rules are written to a single Makefile, to avoid the horrors of recursive make invocations.
It's obvious that a whole lot of the functionality of autotools would be lost, but maybe this transition would nevertheless be worth it. Because my experience with autotools is that every time this tool updates, there's always a project which no longer builds because something that used to work doesn't work anymore for whatever reason. And it's surprisingly hard to force autotools to rebuild all of its intermediate files, which makes debugging autotools build issues doubly frustrating.
I think autotools' problem is the fundamental design on utility written in one programming language generating code to be run with another programming language that generates code/data for yet more programming languages. Use of code generators always seems to result in an unworkable mess, so they really ought to be off the table. (Ideally there would not even be a Makefile as the output, but maybe that file is acceptable enough...)