SSHFS mount option default_permissions does not support ACLs - please explain

Question

In regard to the FUSE GitHub page, I have some questions:

1. Does the quote below mean SSHFS does support ACLs if default_permissions is not used?

2. Does it mean that if one needs ACL support and proper security, neither default_permissions nor allow_other should be used as mount options? (It is very clear that allow_other should not be used without default_permissions.)

3. If #2 is correct, does this mean that SSHFS mounts without default_permissions and without allow_other will correctly pass along the server's file-permissions and ACLs to the clients?

Source: GitHub - libfuse/libfuse: FUSE (Filesystem in Userspace) interface https://github.com/libfuse/libfuse

If you intend to use the allow_other mount options, be aware that FUSE has an unresolved security bug: if the default_permissions mount option is not used, the results of the first permission check performed by the file system for a directory entry will be re-used for subsequent accesses as long as the inode of the accessed entry is present in the kernel cache - even if the permissions have since changed, and even if the subsequent access is made by a different user. This is of little concern if the filesystem is accessible only to the mounting user (which has full access to the filesystem anyway), but becomes a security issue when other users are allowed to access the filesystem (since they can exploit this to perform operations on the filesystem that they do not actually have permissions for).

This bug needs to be fixed in the Linux kernel and has been known since 2006 but unfortunately no fix has been applied yet. If you depend on correct permission handling for FUSE file systems, the only workaround is to use default_permissions (which does not currently support ACLs), or to completely disable caching of directory entry attributes.

In my environment, all clients and servers run Linux and all use BTRFS (which supports ACLs). All GUIDs and UIDs match.