@climagic
I think this picture is close to the limit, if not past it.
It's not possible to visualize all aspects of linux filesystem in a single 2D picture, and with VFS and mountpoints you're already stretching the analogy.
The picture is awesome, don't ruin it by trying to stuff more things into it.
@climagic
as for VFS & mountpoint specifically:
AFAIU they're only involved in metadata operations, once you have an FD and are writing or reading actual bytes in the file they stay out of the way, and that's hard to represent in the picture.
I think their inclusion is a net positive because you already have the block device and its driver, so people might ask "ok but how does /dev/sda1 become /boot", but from the PoV of "which bytes on disk represent what" they're not present.

@climagic
On most modern systems, the operating system will offer (Linux install) or come with default encryption (Android/iOS) at the OS level. Additional to the (earlier mentioned) possible encryption at the device level.
Also I think _if_ you want a file example with multiple contents. I'd go for a mkv or webm file with 1 video, multiple audio and subtitle streams and their metadata. Or maybe an office file (odt/docx) which are actually zip files that contain a ton of files.
@climagic you could add more layers if you wanted: gz > tar > eml > MIME > base64 > jpeg > steganographic message.
Of course, you could add infinite containers. Something something it's turtles all the way down.
These are really nice. Good job!
@climagic
Might be a bit too much, but maybe include boot code? Also, might want to use gpt instead mbr as that is more common these days.
Not sure why you have partition table separate from mbr, as mbr contains the partition table.
Or do you mean something other than:
https://en.m.wikipedia.org/wiki/Master_boot_record
?
@climagic Another way to approach it is (using typical Linux/UNIX implementation) that each file that you can see in a directory is a directory entry pointing to an inode. Usually there's only one directory entry referencing an inode, so when you delete it, the inode is marked as free, as are indirect blocks and data blocks referenced by the inode. A free block is usually not zeroed. Lots of inode images around.
Kudos for including the overprovisioning (wear leveling) blocks used by hardware.