Here's a philosophical question: what do Unix errno values mean?

One possible meaning is that they are hints about why your system call failed. Another possible meaning is that they specify what went wrong; in the extreme, a system call can only fail for certain specific reasons, each of which is associated with a specific errno value.

Errno as a hint is essentially the traditional Unix view. V7 Unix didn't even document specific error returns for system calls, and Bell Labs took it to the logical extreme in Plan 9, where system calls return error strings instead of fixed error numbers.

(There are reasons to use fixed error numbers instead of strings even if errno is just a hint; it helps internationalization, for example.)

Errno as a specification and contract is in full flower in Unix specifications like the System V Interface Definition, POSIX, and the Single Unix Specification. Their documentation is full of promises that system calls must return specific errno values in specific circumstances (and sometimes, must never return other values; what you are supposed to do if the system call fails for some other reason is not specified).

I'd say that the specification writers created this situation, but I don't think that's entirely fair: in a sense, the situation is the fault of BSD Unix's support for non-blocking sockets. Various important bits of state information are communicated via errno values, and this can only work if those errno values are a contract instead of a hint.

In practice, you are much safer considering errno as a hint (outside of a few errno values when working with non-blocking sockets), because this is the reality on at least one popular Unix. (I suspect that it's the reality on most popular Unixes, but I haven't checked.)