access(2) can return errnos that correspond to input errors or general system faults, such as EINVAL, EIO or ENOMEM.  In this case, an exception should be raised instead of returning False.

It is probably best to whitelist those errnos that indicate missing access -- it needs to be discussed whether that is just EACCES, or also e.g. ENOENT.

The list of errnos indicating missing access seems open-ended.
Things such as:

[ENAMETOOLONG]
    The length of a component of a pathname is longer than {NAME_MAX}.
[ENOENT]
    A component of path does not name an existing file or path is an empty string.
[ENOTDIR]
    A component of the path prefix is not a directory, or the path argument contains at least one non- <slash> character and ends with one or more trailing <slash> characters and the last pathname component names an existing file that is neither a directory nor a symbolic link to a directory.
[EROFS]
    Write access is requested for a file on a read-only file system.

... may be considered missing access.

I don't think we can change this for the maintenance branches. The code behaves according to the documentation:

    access(path, mode) -> True if granted, False otherwise

"False otherwise" is really meant that way: otherwise. The specific condition is indeed not communicated. However, applications are entitled to not seeing exceptions come out of this function.

I would be in favor of changing this in the long term, but then raise exceptions in all cases. Alternatively, have it produce falsish values that encapsulate the error code.