With persistent memory you don't need that extra serialization/deserialization step to/from the filesystem. Look, think it like this:

1. In memory we store our program code and data as blobs in various parts, in the stack, in a heap, some only for the current program, other stuff like shared libraries linked at runtime to various programs. It's a rats nest of pointers.

2. When we "save" or "restore" we takes that rats nest and pull out some of the important parts (e.g. we ignore the shared libraries in memory and the app code) and we serialize that state out to disk.

3. Then the file system takes that logically contiguous "file" and breaks it up into pieces and stores those across the disk in various blocks and writes metadata which describe how to put the pieces back together again.

With persistent memory we can ignore steps 2 and 3 most of the time, but they still might be useful for sending data to other computers, especially step 2.

Disclaimer: I read the slides but didn't watch the talk

1. Download pictures from camera. You need a program to transfer them somewhere you can find them.

2. Choose 12 of them to make a calendar for next year (OK, let's assume we're already in November). You need a program to view them.

3. Edit them with your favorite. Save as copies, not to overwrite the originals.

4. Upload them to a web service using a browser.

A file system is useful to support all of these steps. Android's share to other apps kind of hides the file system but it doesn't succeed 100%. Sometimes no app registered to handle some file type and we end up picking the file in a file explorer interface. Sometimes we even have to know where that app stores its files. My most usual case for this are the gpx files of OsmAnd, when I transfer them from the small phone I use as tracker to my main phone.

However, you've given me the idea of what if instead of registering to handle a file type and giving the user a way to select a file we made sharing better by making applications provide a kind of "Files" view in to their data which may simply be items in their databases. On iOS the app ShellFish provides a seamless view to the files on my servers inside of the Files app and the Files picker of the OS. In macOS the finder's file picker has a section for Photos which lets you select a photo without needing to export it to a specific file. We could instead select from applications on our system instead of going to each application and sharing each piece of data we need.

In my example, that camera is storing pictures on a removable media, maybe FAT32 even in 2050. And there are good reasons for that: I saw mode than one person filling more than one 64 GB SD card with pictures on a 3 weeks journey.

And at the end of the example the machine that prints the calendar might want individual files and reset its state at the end of each print. It can even be a way to resist to attacks that upload malicious pictures.

I personally believe that files are still a useful metaphor, and this hypothetical OS that we're discussing would likely still provide them, at least for interop.

An example being a database. Provided we didn't have to batch writes, be aware of dirty pages, write things in certain order to maintain coherence in the event of a crash, etc... we could build something really simple. Ultimately it would depend a lot on the details like memory bandwidth+latency between DRAM and NVRAM

But over time, people tend to name the key using a path structure, separated by forward slashes, to give a logical separation of data into subdirectories.