Exit statuses should implement a protocol between the calling and called process. Since only 8 bits (or 32 if the calling process uses waitid()) are available, there is not much flexibility. I think distinctions between different exit statuses should have a purpose, while most of the sysexits codes categorize errors without a clear purpose. If more flexibility is needed, a channel with more capacity should be used.

I think only EX_TEMPFAIL (75) has a clear and reasonably generic purpose, and I think it is fine to use it when the calling program expects this status, which requires the called program to be aware of the context to some degree. Alternatively, a temporary failure might be considered "false" (1) and a persistent failure "failure" (2), per the second below protocol. This would probably a more consistent way to write lockf(1) in 2020, but changing it now is probably not a good idea.

More portable conventions are as follows:

The two commonly used protocols are:

• 0 = success, >0 = failure
• 0 = true, 1 = false, >1 = failure

Additionally, there are common conventions when a program starts another:

• 126 if the other program was found but could not be run
• 127 if the other program could not be found
• 128 plus the signal number if the process terminated abnormally (note: POSIX only specifies "greater than 128" and that kill -l exitstatus can be used to find the signal's short name)

In D27176#606806, @jilles wrote:

I think only EX_TEMPFAIL (75) has a clear and reasonably generic purpose,

when composing D27161 , i found the only unambiguous error code to be EX_OSERR which i used whenever a syscall failed