A lot of storage these days is in object storage like S3. There’s no partial writes, file permissions, extended metadata (it might have this actually), or directories. It just does what you want most things to do: stores a bit of data that can be retrieved later using some key. You could imagine storing a shared library or or executable just about anything in that or a similar fashion. In fact, I’m using Fedora Silverblue, which is a Linux distro that stores most of its root filesystem in a git-like content-addressable ostree repository (potentially even stored in object storage on the remote update servers). The filesystem is just a formality because that’s what software is currently written to understand.

And even document storage is stored this way in cloud services. Google Docs and Office 365 are presumably just storing their documents as a group of objects. A Word document is a zip file containing XML files and other assets. In a cloud environment, that can be exploded into separate objects for faster updating.

Filesystems don’t even support atomic transactions other than file renames. Windows NTFS used to have this but it was buggy and now basically unsupported. The performance characteristics of filesystems are also really unpredictable (when is your flash storage going to do a garbage collection?) and they don’t have a whole lot of features for doing performance-sensitive things outside of escaping the filesystem altogether. Relational databases just preallocate larger files and then use filesystem-specific operations to avoid a bunch of churn in the write-ahead logs and such. Since they have their own durability mechanisms.

I think a virtual-memory like addressing system could also work for persistent storage. You basically keep all the bookkeeping stuff that filesystems do to keep track of free space, but without the variable-size files with extents and permissions and all those shenanigans.