raph, your comments on GNU autotools are pretty must spot on, but I think your point number 3 is inaccurate. It's not that everyone uses the GNU toolchain; there are applications where other compilers are still interesting, Solaris is still alive as a vendor unix in the free software space, and as you point out, Apple has heavily modified the linker in MacOS X. So there are at least three common platforms that require special logic for building shared libraries, for example.
Rather, I would say that the reduced diversity as the vendor unicies become less relevent brings the issue of dependency detection and configuration to the forefront. And those are precisely the areas where the autotools approach of a maximum-portability script that tests the local system configuration is weakest. The imake style where the build tool knows what's installed is much more efficient here.
In fact, if you already know sh (portable or not) and are willing to depend on pkg-config (as most gtk/gnome software now does) you can do almost as well with just GNU make + pkg-config. The text substitution operators of the former do most of the convenience (as opposed to portabtility) features of automake, and the latter can do most of what autoconf is now used for. The rest of the configure script can just be implemented in the Makefile rules.
Still, I'd also like to see one of the more modern build tools take off, especially something that would flatten the learning curve for these things. SCons seems to most promising of these, but it still has a ways to go before it becomes a compeling replacement for larger projects.