We are going round in circles so I'll have one last attempt to explain my point :)
> I never claimed it's Linux only, only that there are other systems with different semantics.
Maybe you shouldn't have said "Linux-specific" if you didn't mean it was specific to Linux.
Also I demonstrated that FreeBSD + ZFS behaves the same as Linux on my system. I cannot comment about why your example didn't work the same. Perhaps you were using UFS instead of ZFS? Or non-default file system mount options / or other tweaks? Aside running ZFS as root and having compression enabled, my root zpool is pretty vanilla. But either way, it goes back to my point that this is a file system specific behavior not an OS-specific one.
> ...except that FUSE is in-kernel mechanism to delegate VFS callbacks to userspace program. It's hard to argue in such a case that the work is not the kernel's responsibility.
Your counterargument is just reiterating my point. File systems compiled against FUSE do not run in kernel space. The kernel syscalls obviously need to hook to your file system still (which is where the FUSE wrapper comes into play), but the FUSE API does all the user space / kernel space memory swapping so your actual FUSE file system doesn't run in the kernel.
This will obviously cause some extra overhead but with the exception of ntfs-3g, most file systems compiled against FUSE tend to be less performance-orientated anyway (eg they might be network bound). But as an aside note, this is also why I don't recommend people using ntfs-3g on low-footprint devices like the Raspberry Pi.
> Oh. This explains quite a bit, because I thought the argument was about whether the OS' usual semantics (group being inherited from directory or from EGID) are like that or not, not where in kernel this behaviour is coded.
> No, I'm making the case that Linux usually works one way, and BSD usually works the other way. I never claimed that anything was coded in any specific kernel subsystem, so don't add the statement yourself.
I know, I was the one that brought code into the debate. I did so very deliberately because software is code and you were making a point about the behavior of software. I'll I'm saying is that I don't agree with you that this behavior is OS-specific because the behavior is defined by the file system. Ie one file system could handle this behavior differently to another file system on the same OS by default. This is why I make a point about "where in the kernel the behavior is coded". It's not just an academic point, it's directly refuting the entire argument you've been having.
Anyhow, since your profile lists you as a developer as well as systems administrator - and you clearly do have a good understanding of the underlying architecture of BSD and Linux - I suggest you play around with a hobby file system yourself. It's good fun and FUSE is dead easy to learn as there will be bindings for most popular languages. I did mine in Go using an API that closely mirrors FUSE's C libraries but I've seen that most higher level languages (eg like Javascript) have FUSE bindings too - if that's your thing instead. Or obviously there's Rust and C/C++ if you prefer to work more directly with FUSE. You don't even need to work with hardware since you could just wrap FUSE around MySQL queries (as one of my latest experiments does) or even contents described in an ASCII file (as my first project did). Because Linux / BSD / whatever doesn't handle the actually writing of the file system (and why would it?), it means it's up to the file system to implement whatever set of behaviors surrounding permissions it wants.