> И то, что в идеале оперативная и долговременная память объединятся - это вообще никак не поменяет.

Мне кажется, что это чересчур сильное утверждение.

Существуют примеры софта, который инкапсулирует фс и файлы, и общается с пользователем в иных терминах. Взять тот же calibre. Общение с calibre идёт в терминах отдельных книг, но не файлов. calibre где-то там хранит у себя книги, и делает это в виде файлов, но те файлики где-то лежат, и в каком виде они лежат, где именно -- это уже не те вопросы, которые волнуют пользователя. Если бы адресное пространство Calibre целиком бы мапилось на NVRAM, то он бы мог не создавать никаких файлов, а непосредственно хранить все книги в ОЗУ в представлении заточенном на RAM.
Можно ещё для примера взять браузерный кеш. Там, с точки зрения человека, очень неудобно используется fs, куча файликов с непонятными именами, и маппинг url -> имя файла выполняется через sql. Тут опять же fs полностью инкапсулирована, и весь этот кеш можно было бы хранить в RAM формате в адресном пространстве, не заморачиваясь на обеспечение способности скидывать содержимое RAM на диск в виде sql и кучи файлов.

Это лишь два примера, которые пришли мне в голову. И оба этих примера, в сегодняшнем исполнении, имеют как RAM представление хранилища, так и дисковое представление заточенное на хранение в файлах на блочном устройстве. В обоих этих примерах можно было бы выкинуть кучу кода связанного с реализацией обратимого отображения RAM представления в дисковое представление.

То есть, файловая система как хранилище данных легко может уйти в прошлое. Проблемы с избавлением системы от файлов начнутся в тех случаях, когда файлы используются как своего рода IPC. Скажем, /usr/src/linux хранит кучу файлов, которые используются не только как хранилище информации, но и способ передачи этой информации от одного приложения другому. make, gcc, git, текстовый редактор -- они посредством файлов передают информацию друг-другу. И вот такое использование файлов будет сложно заменить чем-то ещё. Можно, но это потребует изобретения какого-то нового способа прокидывать информацию между приложениями, и может быть этот способ даже будет лучше чем фс, но зато он будет менее универсальным. А это значит что либо придётся изобретать не просто так способ, но универсальный способ, либо для каждого подобного случая изобретать новый велосипед.
С другой стороны, есть же fuse... Да! Глянь. Фантазируя чисто гипотетически. Возьмём git, перепишем его под использование nvram, так чтобы для каждого git-репозитория мы бы запускали отдельный процесс, и всё содержимое этого репозитория хранилось бы в адресном пространстве этого процесса. Там всё равно всплывёт понятие файла, но оно не будет привязано к ограничениям блочных устройств и при этом оно будет заточено под задачи git. Теперь, git регистрирует fuse файловую систему как чистой воды IPC, и всякие там текстовые редакторы, make, gcc и прочие бизоны общаются с git через fuse-интерфейс. А если ещё каким-нибудь образом научить этот fuse интерфейс переключать контексты при вызовах open/read/write не через ядро, а непосредственно между процессами, чтобы каждый такой "сисколл" приводил бы к _двум_ переключениям контекста -- туда и обратно, -- а не к четырём: клиентский процесс -> ядро -> fuse-процесс -> ядро -> клиентский процесс... Если как-то извернуться таким образом, то это будет даже не медленнее чем при использовании ядерной фс, а скорее всего даже быстрее, потому что данные организованы не в фс, которая заточена на общий случай, а специальным образом заточенным именно на данный класс use-case'ов.
Ядерная фс прекращает существовать. Вместо /etc мы запускаем etcd. Вместо /bin, /sbin/ /lib и прочих, мы запускаем ldd. Вместо /home/user мы запускаем DE и разнообразные софтины на разные случаи жизни.
Правда напрашиваются проблемы с бекапами. Если плазма упадёт, то будут утеряно всё то, что пришло на замену /home/user.