2 just sounds like reinventing the file system, now with more bugs.
Finally, as I said, it is a straw-man proposal -- I haven't spent time working out all the kinks.
So flock() and file permissions then?
There are improvements that could be made here -- app-level permissions in addition to user-level permissions for example. But it's still fundamentally a filesystem.
We are talking about what the user/application sees and is capable of accessing.
But how is that different than a filesystem?
Suppose we add application-based ACLs to file permissions. Then the app does open("/path/to/file", O_RDONLY) as ever. If the app has permission to the file, it gets the new fd. If it doesn't, it gets EACCES as usual. Or the OS displays a dialog asking whether the app should have permanent or one-time access to that file, and then the call doesn't return until the user chooses one.
I don't see a fundamental change here. The application wouldn't necessarily even have to be modified.
Historically mostly because of swap, so the OS can move a page from memory to disk and then back to a different physical memory location without modifying the application's pointers. On large systems with 32-bit applications it was advantageous because the system may have had more memory than 32-bit pointers can address and then each application can have its own address space. ASLR nowadays.
But filesystems already have the equivalent abstraction. If you run out of space on /dev/sda you can add /dev/sdb, copy /home to it and then mount /dev/sdb1 /home and the application that reads /home/alice/file is blissfully unaware that anything has changed. Heck, half the time you're not even reading from the physical drive, the data is cached in memory and you're really reading it out of the page cache.