I'm on the side of testing for features in a realistic, reasonably modern context which takes into account a set of supported platforms.

There is no point in testing for things for decades-old systems if you don't have any users on such installations.

The Autotools approach isn't overkill; it's overshoot. To declare something overkill, it has to solve the problem fully. Most of the Autotools-build packages in a GNU/Linux distro will not work on ancient systems, so they don't actually kill that problem. Even if the configure script actually runs through (unlikely), it will fail to detect things that the programs need. There won't be any fallbacks and so things won't build. If things happen to build, they might not run properly.

Porting requires work. You don't develop on system Y and assume it works for users of system X because you're on Autoconf. To call system X supported, you get a system X box with a development environment and port X. That is why, subsequently, the configure script works on system X flawlessly and everything builds.

I'm not the parent commenter, but experience has taught me that testing for features, not versions, is definitely the right way to go. The alternative ends up with you creating a hodge-podge database of which features are present in which operating systems / versions, which is inevitably out-of-date, incomplete and wrong.

Only test for the features you actually care about, though. And at this point, it's perfectly fine for a new project to assume some baselines like POSIX-1996 and even C99 (unless you're targeting Windows...).

Testing for features is the right way to go. If you add support for a new platform, there is no guarantee that the tests will all magically work. But a lot of them, in fact will. That reduces the amount of remaining work.

You could have a canned set of files, one per platform, containing some canned settings of variables. (The Pine e-mail program was a good example of this; its Alpine successor uses Autoconf.)

If you are porting to a new system, you have to guess which of the existing canned configurations is the closest one that will work and use it as a template.

Since there is no logic to detect if any of the features related to the configuration variables is actually present and in what form, it's just guesswork. Okay, it doesn't build. Now which of the relevant variables in the canned config is related to that breakage?