Parallelizing a shell script

Yes, this! At a libc API level, actively-maintained POSIXy operating systems are more similar than they are different, and the fastest possible configure check is the one you don't do.

The first portability decision to make in a project is whether it aims to be POSIX-only, or whether it aims to be portable to Windows. POSIX and Windows are sufficiently different "shapes" that if both are supported, in practice there are going to be two code paths anyway; and it's likely that it will be easier to test "#ifdef _WIN32" or ask the build system "is this Windows?" rather than inventing configure checks that end up meaning the same thing.

For the POSIX code path, if you choose a baseline level of functionality and say that you require it, a lot of configure checks become unnecessary: there's no point in checking for "normal POSIX things" unless someone has gone to the effort of testing a code path for specific platforms where they're missing (and it's 2025, so 1980s proprietary Unix is probably out of scope for most projects now). Similarly if you can nominate some reasonable C standard like C99 or C11 and say "your compiler must be at least this modern", or the equivalent for C++, then there's no need to feature-test for individual functions from that standard.

Similarly, for the Windows code path if you have one, if you choose baseline Windows/SDK/compiler versions and assume them, then configure checks for anything provided by that baseline are just a waste of time.

Depending what the project does and how much OS integration it needs, some projects will also need a special code path for the macOS/iOS/etc. family, or for Android, or something like that. Again those are easily detected at the preprocessor or build system level.

*Then*, after distinguishing between those major code paths, it becomes useful to do feature-tests for whether particular corners of functionality are available or not - but every time there's a feature-test for whether there is a frobnicate() function, it should be because the project's source code is genuinely looking at whether HAVE_FROBNICATE is defined, and doing things differently in the case where it is, and the case where it isn't.