Consider the following:

• An Evlan program's static data files are stored along side its code, and loaded via the "import" keyword.

• Evlan programs store dynamic data in memory, not to the filesystem, relying on the VM to handle persistence.

• Evlan programs generally load and save user documents solely via drag-and-drop.

Therefore, a typical Evlan program has no need for direct access to any filesystem.

The only time an Evlan program comes close to direct interaction with the filesystem is when the user drags a document into or out of the program. This document doesn't necessarily have to be a file on disk, however. It could perfectly well be an object stored within another Evlan program.

In other words, a plain old Evlan program can perform all the duties of storing and organizing a user's documents. That program might be based on a hierarchical organization like current filesystems; it could be based on a searchable, sortable database (such as the iTunes library); or it could work in any way imaginable. The user could use only one such program for storing all their files, or they could use many, using different types of organization schemes as they make sense.

With such programs serving the user's document organization needs, a pure Evlan system has no need for a system-level filesystem whatsoever! Instead, the hard drive can simply be looked at as a gigantic swap space, and can be organized in whatever way the individual Evlan implementation likes.

This is just one example illustrating how much simpler a pure-Evlan operating system could be.