But that's the point - web authors are supposed to use feature detection instead of writing to a particular standard version. It turns out to be a better model for large interfaces. Yes, in theory, you can ask "Is this OS POSIX.1-2008-compliant or not." In practice, it takes a while to e fully POSIX.1-2008-compliant, and so you get autoconf, with its individual feature detections of specific function. Less clean, but way more practical.
If you're writing an embedded renderer, you can always say "This is compliant with the standard as of 14 December 2017." If you're writing an embedded renderer that is being applied to the live web and not just to a fixed set of pages that are also embedded (e.g., you're shipping HTML documentation and a viewer, or a kiosk, or something), you will in fact be out-of-date when the living standard changes. There's no point in saying "I'm compatible with HTML 5.2.0" because the live web isn't targeting 5.2 any more. So you can either acknowledge that, or figure out how to get software updates.
How does one perform feature detection in a static HTML page?
As far as I can tell the only way to author a compatible web page these days is by checking every damn feature of HTML you use against some humongous table like Can I Use? before assuming your audiences' browsers support it.
Compare to versioned specs, where I need simply determine the minimum spec version supported by my target audience (and any exceptions to the spec) and code against that spec.
There is some utility in naming sets of well-supported features...
This is the annoying part. It's a joke that a site like Can I Use needs to exist, and that browser vendors don't really have apt versions of their own compatibility tables.
Going to a third-party website to check to see if something is supported is disgusting.
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.
If you're writing an embedded renderer, you can always say "This is compliant with the standard as of 14 December 2017." If you're writing an embedded renderer that is being applied to the live web and not just to a fixed set of pages that are also embedded (e.g., you're shipping HTML documentation and a viewer, or a kiosk, or something), you will in fact be out-of-date when the living standard changes. There's no point in saying "I'm compatible with HTML 5.2.0" because the live web isn't targeting 5.2 any more. So you can either acknowledge that, or figure out how to get software updates.