The problem with autoconf is that it detects every conceivable Unix featuring going all the way back to the 1980s, not that feature detection is itself that problematic.
Right, hence my assertion that well-known names of feature sets are useful. "HTML 5.2" is useful in the same way that "C99" was, because eventually there is a day I can just assume everything in "HTML 5.2" is present in all my targets. If I don't have such a name, if I'm forever at "HTML 5", I'm forced into the "autoconf" scenario of using feature detection forever for everything not in the base specification.
(That the W3C is apparently incompetent at associating feature sets with names is a separate issue.)
It's funny that you use C99 as an analogy. Please list all the compilers you support that support C99. I'll give you a hint--MSVC, Clang, and gcc all don't support C99 fully, and possibly never intend to. It's not just an idle "oh, no one cares about those features; they support it for all intents and purposes": gcc kept its default standard at C89 in part because it didn't support C99 fully.
What you're doing when you say that you assume C99 compliance is you're thinking of the features from C99 that you want to use and relying on that. Admittedly, the generally-unsupported features are very niche. But that means that you potentially have a dozen different ideas of what "we support C99" actually means, and that's before you start asking how reliable an implementation needs to be before it meets the definition of "support." Declaring support for versioned standards is often more problematic than helpful (versioned implementations is a different story).
The real problem with autoconf is that no one removes the unnecessary feature checks and no one audits it to see what's still necessary for the platforms that people intend to support.
"C99 is substantially completely supported as of GCC 4.5 (with -std=c99 -pedantic-errors used; -fextended-identifiers also needed to enable extended identifiers before GCC 5), modulo bugs and floating-point issues (mainly but not entirely relating to optional C99 features from Annexes F and G)." [1]
Sounds fully supported to me, for all practical purposes.
autoconf doesn't detect much of anything by default. A few commonly used, boilerplate macros do a series of test (e.g. AC_PROG_CC, AC_USE_SYSTEM_EXTENSIONS, AC_SYS_LARGEFILE), but for the most part each and every feature test autoconf does was explicitly and individually requested by the author.
The real issue is that people copy+paste autoconf tests from other projects without thinking about whether they're necessary, or even confirming whether they work for their use case. And because people just copy+paste autoconf tests instead of keeping a browser tab open with the (free) POSIX spec when writing their code, most tests people add are for stuff that no longer needs to be tested for (i.e. all the major Unix platforms support most standard POSIX features by default), and lack the tests for non-standard interfaces they actually use.
But there's no easy way to fix such poor development practices. A good start would be if people just stopped using autoconf, as well as libtool, cmake, maven, etc, unless and until it really became necessary. Follow the KISS principle. Keep your build as simple as possible and regularly test your code on at least one platform other than Linux/glibc, such as FreeBSD or OpenBSD, rather than misplacing your faith in overly wrought tooling.
It works the same way on the web. Don't use the latest + greatest feature if you don't need to. Like with performance optimizations, don't add the burden until there's relevant, empirical evidence that it's worth your while in the particular case. Nobody ever magically achieved high performance or strong portability by adopting over wrought tooling before the problems ever presented themselves. Doing so often ends up with the opposite result.
