This is an invitation for a discussion more than a legitimate suggestion, but why do we seem to prefer fprintf calls (and multiple of them) in base userland instead of a single fputs (or fputs_unlocked maybe) call?

I can imagine you had a reason not to do it like this, but I can't think of anything specific.

Wouldn't a break do the same? It'd look more consistent and idiomatic, in my opinion.
Or call exit(0) like you do in case OPT_HELP.
And/Or make help call exit(0) like version does, then replace calls to usage with calls to help and remove usage altogether.

If I'm not wrong about this, I think it's worth fixing to make the new program a bit more consistent from the start.

I missed that usage exits with 1. But still you could parameterize help and call it directly, and then remove usage.

I can imagine you had a reason not to do it like this, but I can't think of anything specific.

You've explained this, but in the comment for the whole function, so I missed it.

Premature optimization. The compiler will replace the fprintf() call with more efficient code if appropriate.

This is not needed.

I think you're missing the directive to install the manual page?

No, it's implicit, as long as it goes in expected section.

(you'll have to #include <sysexits.h> at the top)

You'll need this to prevent mandoc from inserting random line break within the author section.

Maybe take a page from lld
LLD 14.0.5 (FreeBSD llvmorg-14.0.5-0-gc12386ae247c-1400004) (compatible with GNU linkers)

e.g. something like
(compatible with GNU coreutils 8.32)?

but just a little bikeshed point

that would miss the point, i noted in the ocmment this is whitespace-compatible with the original:

nproc (GNU coreutils) 8.32

if some funny program decides to --version and grab the version, they will get a sane number

but some silly program may equally do something like nproc --version | grep -q "GNU coreutils"

other tools like ls don't do it, so i'm going to scratch this bit

that would be most peculiar

not really, the reason lld has the peculiar version string is that libtool does essentially this (I think it may just grep for GNU though)

but the code cannot claim to be gnu coreutils and even then, grabbing the version number from it runs into the whitespace issue i mentioned.

The code didn't check whether the result of strtol would fit into the int ignore. This means a user could cause an overflow, which is UB. In reality this means that very large values might wrap around into the accepted range and the program would run successfully without doing what the user intended.
It also didn't check whether the argument consists only of digits.
strtonum simplifies all this and provides a nice error message. If you want to go down this route, you need to declare const char *errstr and include limits.h for INT_MAX.

fair point, thanks!