The problem however is that thousands of projects that still haven't updated. Gentoo developers are trying to patch the packages but as can be seen in [1] that tracks all the relevant bugs, not even half of them are fixed. Also those are fixes in Gentoo - AFAIK while the Gentoo devs are trying to upstream their patches, not everything is patchable. Note that i mention Gentoo since they were the ones that showed up in the discussions i've seen, but the same is case with all distributions (and projects like Homebrew, etc) - it is just that most likely Gentoo users were affected the most as they build everything from source and can use Clang for that.
But there seems to be two additional issues with Autoconf specifically (remember that this isn't just about Autoconf, it is just that due to how the existing Autoconf checks were written, configure scripts generated by it are the most likely to encounter the issue):
The first is that while there have been fixes for the failing checks, there hasn't yet been a new release of Autoconf that uses these checks - when i run a freshly regenerated configure scripts on my PC with the latest stable release as provided by my distribution i still get the failing checks if i force Clang 15 to use the options that were previously disabled. This means that any configure scripts generated right now will fail when those become enabled again.
The second is that some widely used macros in Autoconf[2], those to find if a library exists and to find which library exposes a symbol (e.g. if libm is needed to be linked to access the functions in math.h or they are part of the standard library - different OSes still need different options here) do it by writing and attempting to link a small C program that defines the function as (IIRC) "char the_function_name();" with code that calls that function (the function is not actually called, the check only tries to compile and link that program) and if that fails it assumes the library does not exist / does not support the function. Problem being is that the above fails with Clang 15.0.0 because of the "()" part (should have been "(void)" but when the check was written many years ago it was meant to work with pre-C89 compilers that didn't support the void keyword). This is fixed in Autoconf now but as mentioned above, no release yet so any currently made brand new configure script will have this check failing. But the more important issue is that this check seems to be a ticking bomb - at least as far as Clang is concerned - since it can trigger various errors in the future and judging from the responses by one of the Clang developers[2] (i actually recommend reading the entire thread) they seem to be of the opinion that treating this as an error in the future is something they might do as it is technically UB. As of right now there hasn't been any fix for this and from the discussions from that thread, the Autoconf developers do not seem to be able to figure out a generic solution (the only solution they found is to include prototypes for all known libc functions but this wont work if you, e.g., want to figure out if the system has curses or ncurses - as an example NetBSD needs -lcurses not -lncurses, at least last time i checked). So even if a new Autoconf release is made now, the configure scripts might still break in the future if Clang developers decide to make this an error (AFAIK even without a release some distros have patched Autoconf to fix the errors introduced and reverted in Clang 15.0.0 but even those do not have a fix for the above).
Also all these are about freshly generated configure scripts, in practice there are projects out there where their configure scripts haven't been regenerated for a long time (often because there hasn't been a new release for a long time). Though many of them can be brought up to date with "autoreconf -fi", assuming of course the fixes i mentioned above are available.
(FWIW from what i can tell this isn't a problem with GCC and the devs contemplated adding a special check for Autoconf generated code to skip the errors if they decide in the future to make these errors, but of course this only affects Autoconf - while i focus on it, Autoconf isn't the only affected program - and regardless the entire point of Autoconf is to allow whatever compiler and tools there are around instead of requiring specific ones from the user)
Considering the above i wonder if Clang 16 decided to proceed with the changes regardless. The release notes do mention some changes that might affect configure scripts[4] but i'm not sure if the notes there are just some heads up for people making configure scripts to check for potential breakage in the future or honeyed words for "technically not every configure script will break, so hey, we warned you". This is a bit amusing since if you check in the discussions i linked to, a concern others had was that the release notes in the version of Clang 15 barely made a mention of the potential for breakage.
(as a side note, all the above focus on Autoconf might sound like me ragging on Autoconf/Autotools, but this wouldn't be farther from the truth - having built a lot of software from source code, including on minimal non-Desktop non-Linux Unix-like environments like NetBSD, i absolutely love that Autotools-based releases do not require anything that isn't already there in a Unix-like environment to work and even recently decided to use it for some of my own projects because of that, which is how i found all the above. From a practical perspective it isn't that hard to work around the issues even with existing configure scripts - AFAIK some of Gentoo patches do exactly that - so despite all the above it is still my favorite build system to build stuff with as a user... as a developer, well, i haven't found it to be any worse than other build systems)
[0] https://discourse.llvm.org/t/configure-script-breakage-with-...
[1] https://bugs.gentoo.org/870412
[2] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/a...
[3] https://lists.gnu.org/archive/html/autoconf/2022-11/msg00006...
[4] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNot...