One of the issues still pending in the overlay filesystem approach is how to handle persistent information for a given application in a general way. Some examples of persistent information use-cases:

Most document-editing applications include a "most recently used" list of the documents edited within them that can be selected and edited with a single click. Obviously that's not allowed if we require explicit user selection of a file to allow access to it. The application would have to be altered to request the file by asking the journal to highlight it for the user, but it could not be allowed to directly open the file. That requirement is an explicit requirement of the security system. MRU lists would work in "project" environments reasonably well, but the Journal is already an MRU list in its default view... which suggests maybe the MRU menu itself should be eliminated.

Straightforward preference storage is also desirable. For instance, you will always wish to configure your text editor to use (proper) tabs instead of brain-dead 4-space-per-tab operations ;) . That choice should persist across all iterations of the activity, regardless of which file/project you are working on... except that sometimes you want the preference to be overridden for a given project (because some space-lover is imposing their wrong-headedness on the world).

"Document annotations" provide mechanisms for an activity to store e.g. "bookmarks in a pdf". Those can be rather straightforwardly written to the activity space for the file, but should the user only open the file (not the whole activity space) the activity would still like to have access to the related information.

Aggregate data storage is a similar use case. Old-style mbox mail clients are an example of this type of storage. They want to collect information across a large number of sessions into a single data-store and they always want to have that data-store available.

The actual "how" isn't a big issue (for any given use-case it's easy to come up with an implementation), it's mostly a matter of how to integrate nicely and generally into legacy software. Linux software normally stores its persistent information in consistent, but poorly defined locations (e.g. ${HOME}/.appname or /var/mail/${USERNAME}).

We would probably need packaging software to allow for declaring a persistence (chroot) layout for the user-data directories (i.e. allowing for a persistent area by declaring a sub-directory to be persistent and having the chroot be created with that sub-directory shared among all instances (or better yet, versioned-and-shared)). The idea would be that the activity could declare the appropriate storage strategy at the subdirectory level, with the strategies being tightly constrained.

Anyway, my lunch hour is over, back to paying the bills.