I'm in favor of keeping set_errno().  Not only is it more like C, but
it's also future-proof against a user that will end up really needing
the feature.  If we go for always setting errno to zero, we cannot
change that later any more, because everybody's code will rely on it. 
(An example of possible usage of set_errno(): the user might need to
save and restore the value around a subfunction call that may call more
C function via ctypes.)

I personally don't care if this means a few percents of performance
loss; I don't see how ctypes can be performance-critical in the first
place given its huge overhead compared to e.g. rewriting the code in C.

I imagine that the same approach could work with GetLastError() on
Windows.  (But is there a SetLastError() on Windows?)

Using the native errno instead of a custom TLS value is bad because a
lot of things can occur; for example, adding debugging prints or a pdb
breakpoint between the function return and the call to get_errno() is
very likely to end up overwriting the C-level errno value.  For all I
know, on some platforms errno could even be overwritten by the calls to
the unlock/lock operation that CPython does at regular intervals in
order to let other threads run.  (For example I can easily imagine that
GetLastError() is overridden by the lock/unlock operations on Windows.)