make is the assembler of build tools
I agree with almost everything you say except that I tend to think of make as a build tool assembler. The MakeXS project (which kinda merged with Austria C++ but is very easily separable) does quite alot with GNU make as the basis.
Your first point is that targets and actions are the same. While you're right, make does not make much of a distinction between a target and an action, you're welcome to make some convention to reduce the issue. Actions are somewhat identifiable by the use of the .PHONY: target if you inspect the Makefile. After using them for many years, it appears the conventional targets "all", "install", "clean", "distclean" etc don't really pose a significant risk of confusion.
As for large projects, I have used MakeXS on moderate projects and it has a "pre-build" binary feature. MakeXS will allow you to build and then create a compressed binary of the result. On a regular "make all", if the pre built binary tar exists, it will simply extract the file avoiding long build time. If you want to build from scratch, simply clean the directory, remove the pre-built binary and make all.
As for the issue you raise regarding "make clean" and multiple targets, it depends very much on your source tree. Using MakeXS I advocate strongly on organizing the source tree in a very flat manner where each library or major target has it's own directory and performing a "make clean" in that directory will clean all intermediate files for that particular target. While MakeXS does not do this right now, I suspect that it would not be a big deal to provide a way to clean dependant targets as well.
The "commit by default" issue is I think yet another issue that can be "fixed" by the Makefile. In MakeXS, there are a large number of make variables that can be queried. An example, "make env/MXS_TARGETS" will cause the "all" targets to be printed (at least the all targets that MakeXS knows about). Also "make -n" does give you an idea of what 'gmake' is going to do without actually doing it.
As for scaring anyone away with a "partial build", I think this is a source tree organization issue, and not so much a fault of make. If you use the MakeXS preferred source tree organization, you're not going to have any issues with building more than you want to build.
The "current directory" issue is also one that MakeXS "fixed". MakeXS mandates that there be 2 files in every MakeXS folder. The first is the regular "Makefile" which must include the second, "Makefile.xsi" which are all identical. Makefile.xsi is used to locate the "root" directory and so you have a consistant "environment" across the entire source tree. The local Makefile is usually empty or contains "current directory" specific parameters.
Regardless, running "make" will read the current Makefile and update the first target in the Makefile. That's what it does. While MakeXS still uses the convention to place "all" as the first target, you're more than welcome to make the all target in the root directory.
I won't defend Autoconf. I've fixed many a build error with autoconf projects that was made very difficult by the nature of how autoconf works. It fails the "result of least surprise" rule too often for me to be "comfortable".
As for variants, MakeXS supports "debug/release", "m32/m64" and can be easily extended to support "architectures". A single instance of a source tree can accomodate multiple builds. Again, this is not an issue with make as the "assembler of build tools" but with the Makefiles that provide the policy.
I don't think I can agree that the build tool must accomodate any source tree organization. I think it's important to reduce the number of variables in source tree organization so that conventions can reduce the learning curve.
Resursive builds are not ideal and I think it is hard to create a make based system that does anything but a recusrive build. So this would be a limitation of make. However, as for build descriptions being close to the sources vs close to the root, I'll have to go with close to the sources. One of the most important features of a source tree is having a "separable" one where I can add or remove chunks of my source tree and all the "things" that go with the "chunks" including the build preferences go with them. This "feature" would mandate that the build preferences go with the chunk (directory).
As for listing sources, I think again this would be quite easy with a minor modification to MakeXS and hence not a make-as-an-assembler issue.
If I directed my engineers to assembler to write code today, I would be have some very strange looks. I don't know if it is appropriate for make to be the underlying build system, however it does have the advantage of being available on alot of platforms (gmake in particular which MakeXS depends on). Having said that, I think there is plenty of room for improvement and one of my back-of-the-mind projects is to clean up MakeXS and get away from some of the limitations of make, in the mean-time however, it builds just fine.
Check out MakeXS
I just published MakeXS (http://www.makexs.com/) which solves some of the issues you bring up.
Needless to say, I agree with many of the issues you talk about. The approach taken by MakeXS is to make it as easy as possible for the developer.