Why would 'set be unknown in this case? 'set should be driven precisely
by the C level. If the C function being called returns its error code in
the errno global variable, the 'set should be 'errno for any Scheme
exception raised due that C procedure.

+1, except that this should also be true if the error code is errno-compatible, whether it was put in the errno variable or not.

I disagree. We can have a separate 'errno property for errno-compatible codes that may not originate from C's errno variable.

It's not lying to the user if the 'errno property is well-known and
deliberately designed to be synthetic where the real errno is not
available. We could call it 'synthetic-errno for emphasis, but I'm not
sure it adds anything.

-1 for marking it synthetic.

There are situations where we know the original error value, that value part of a sensible set (e.g. WinAPI error codes), yet we can usefully map that value to an errno equivalent. Why drop the original value or forgo its convenient errno analogue? We can have both.

But why have the 'set property when the number is not part of a finite,

grovelable set?

Because it's a standard convention, which is one of the reasons why I don't like 'set. "Convention" is a rather long word, and "protocol" is long and somewhat overloaded, but I think they indicate a good line of thinking.

We're gonna need a reflection API at some point (i.e. enumerating sets of available errors). Dodging the concept of an enumerable set is just postponing the issue and possibly making our job harder down the road.