> I've always had an implicit understanding that calls with timeouts may, for whatever reason, return sooner than requested (or later!), and the most careful approach is to re-check the clock again.

exactly.  at the system call level you can be interrupted.  re-checking the clock is the right thing to do if the elapsed time actually matters.

> If we don't want select() to silently retry on EINTR, then I think we
should leave it alone.

We should go ahead and retry for the user for select/poll/epoll/kqueue.  If they care about being able to break out of that low level call due to a signal, they should set a signal handler which raises an exception.  I have *never* seen code intentionally get an EINTR exception from a select or poll call and have often seen code tripped up because it or a library it was using forgot to handle it.

We're a high level language: Lets be sane by default and do the most desirable thing for the user. Retry the call internally with a safely adjusted timeout:
  new_timeout = min(original_timeout, time_now-start_time)
  if new_timeout <= 0:
    return an empty list  # ie: the system clock changed
  retry the call with new_timeout