That suggested a design where the files are physical objects that can be individually picked up and moved around.  I found that foamcore with a strip of magnetic tape on the back forms a pleasingly chunky, easily-movable tile. 

Each tile has a decorative border which is intended to encode an ID number, an attempt to squeeze into the tiny venn overlap between machine readable and aesthetically inoffensive.  (Because we already have a camera calibrated to the surface, and these tiles are expected to pack into grids, the algorithm already knows exactly where and how to look for codes, and can hopefully dispense with the heavy QR-like tracking stuff.) 

The thought is that we would have a basket of these blank (but decoratively serial-numbered) tiles, as "blank files".  To add a file to a module, grab a tile, scribble a name on it, and put it on the wall.  When you zap it, an empty text file comes up on your screen, which you can type into, thereby entirely bypassing the file system and Finder windows.  You can think about the tile as "being" the file, in the same way that the spine of a book on a shelf "is" the book.

I'm thinking that these will mostly be "code" files.  "Data" files, such as images, should live in the database.  (The database will always have a dynamic view because data is dynamic.)

I don't really like the distinction between code and database (that is, I'd like the data, and the procedures that transform that data into other data, to all be integrated into a single design, perhaps Nile-Viewer-style), but I don't know how to do that yet.  These physical tile-files seem like a reasonable first step to replace the virtual filesystem.