lrwxr-xr-x 1 1 Jun 22 19:28 .fcpcache -> .
I was wrong. It is a symbolic link that is messing things up for zip. That lowercase 'L' at the beginning indicates it is a symlink and it points to dot (.) which in a Unix file system is a reference to itself.
I don't know why zip would blindly follow symlinks, but it appears to be doing just that. Or it is not looking that closely at the type of file it is processing.
tar defaults to NOT following symbolic links. You have specify explicit tar options to get it to follow a symbolic link, so it is working as you expect.
With respect to OSD2, MrHoffman is much better qualified. While I a VMS (OpenVMS) user/person that wrote programs that ran on VMS and OpenVMS for about 15 years, I did not work inside the kernel.
As to Unix file systems, they vary in how the various on-disk structures are laid out. Because Unix implements a virtual file system (VFS) layer, only specific concepts needs to be implemented, but how that is done is up to the specified file system implementation.
In the original Bell Labs UNIX™️ file system, a directory entry was exactly 16 bytes long. 2 bytes for the inode number (65,535 files max; as 0 was an unused entry), and 14 bytes for the file name.
But that very flat directory does not cut it for larger file systems. BSD changed to a more variable sized directory entry that allowed for 255 character file names and a 4 byte inode number. But there were serious performance issues when there are too many files in 1 directory (think 100's of thousands and millions, which customers seem to love doing). So many file systems started implementing different fast access methods for looking up a filename, or finding an unused entry that was large enough for the filename to be created, etc... When this variability in directory on-disk layout started happening the VFS layer just stopped allowing non-privileged opening a directory and reading it (this is not universal, as some Unix implementations still allow read access). Instead there are functions that will return directory entries so that shell's can implement file wildcard access, utilities such as zip, tar, find, etc... can walk directory trees. And it allows a mix of file systems to be mounted on the same machine and all the utilities can access it.
There are various Unix internals books around, and generally they include something about the file system, but depending on when they were written and which Unix implementation they are written about, they will have a totally different description of on-disk structures. I've personally worked inside of 3 Unix file system implementations, and studied at least 2 others from the outside looking in. And none of them have been Apple file systems.
