The current version of getfacl (2.2.47) seems to ignore the physical option. It
always follow all symbolic links.
For example:
sesr10 /# getfacl --skip-base -RP files/home
getfacl: files/home/johana/.wine/dosdevices/z:/usr/lib64/klibc/include/asm: No
such file or directory
getfacl: files/home/johana/.wine/dosdevices/z:/usr/lib/klibc/include/asm: No
such file or directory
getfacl: files/home/johana/.wine/dosdevices/z:/home/joga: Permission denied
...
z: is a symbolic link to / created by Wine...

It seems that setfacl also ignores this option (or rather, follows symlinks even
when -L is not specified, -P only applies to symlinks specified on the
commandline), which can be rather nasty.
-P does work properly without -R.

On second thought, the fix is still not complete. The new version now correctly
refrains from touching and traversing the symlink, but it still stats it (not
just lstat).
This results in errors for broken symlinks, which are annoying and confusing.
$ mkdir foo; ln -s /nonexistent foo/bar
$ getfacl -R foo/
[snip output]
getfacl: foo//bar: No such file or directory
$ cd foo;
$ getfacl -P bar
getfacl: bar: No such file or directory
The cause for this is that walk_tree_rec always stats a symlink, then sets the
WALK_TREE_SYMLINK flag, which is then used by both do_set (in setfacl) and
do_print (in getfacl) to ignore the file.
The attached patch fixe this by making do_set and do_print first check for
symlinks that don't need to be followed and making a quick exit, and then print
an error afterwards.
IMHO this patch is still quite hacky, and the stat on the symlink should never
happen, nor should do_print or do_set be called on symlinks that are not
considered. However, this approach is slightly more flexible for future changes,
perhaps.