I've got a case where we mount a CIFS filesystem and then later the actual backing filesystem is deleted (but the mount remains on the machine).

When running from a shell, this is the behavior which I see after the backing CIFS filesystem has gone away:
root@1b20608623a246f1af69058acdfbfd30000006:/fsmounts# ll
ls: cannot access 'cifsmountpoint': Input/output error
total 8
drwxrwx--- 3 _user _grp 4096 Aug 15 15:46 ./
drwxrwx--- 8 _user _grp 4096 Aug 15 15:46 ../
d????????? ? ?        ?              ?            ? cifsmountpoint/
root@1b20608623a246f1af69058acdfbfd30000006:/fsmounts# stat -c "%d" cifsmountpoint
stat: cannot stat 'cifsmountpoint': Input/output error

Running mount -l shows this:
//<redacted>/c7e868cd-3047-4881-b05b-a1a1d087dbf5 on /fsmounts/cifsmountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=<redacted>,domain=,uid=0,noforceuid,gid=0,noforcegid,addr=52.239.160.104,file_mode=0777,dir_mode=0777,soft,persistenthandles,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)

In the Python code that I see posixpath.py has this snippet:
    try:
        s1 = os.lstat(path)
    except (OSError, ValueError):
        # It doesn't exist -- so not a mount point. :-)
        return False

The problem is that the comment: "# It doesn't exist -- so not a mount point. :-)" assumes a particular kind of OSError - in reality not every OS error means that it doesn't exist. In this case we're getting OSError with errno == 5, which is:
OSError: [Errno 5] Input/output error: 

Now, I'm not entirely sure what (if anything) the ismount function is supposed to be doing here... but returning false seems incorrect. This IS a mount, and you can see so via mount -l.
I am aware that there are other libraries (i.e. psutil.disk_partitions) which can help me to detect this situation but I was surprised that ismount was saying false here. It seems like it should possibly just raise, or maybe there's a fancy way to check mounts if lstat fails.

This looks kinda related to https://bugs.python.org/issue2466 (although this is already fixed and not exactly the same problem it's a similar class of issue)