This would be a filesystem where directories are just lists of files -- every file has a unique index, the hash of its complete path from the root, so accessing files even in deeply nested directories can be done in constant(ish) time. Files still have inodes, but they need to contain the paths too.
You could use a perfect hash if the filesystem's constant, or if you had some smart scheme for recalculating hashes when stuff changes.
Directory permissions are interesting because you don't normally go through them -- I guess you'd have to cache the effective permissions in the inode and recalculate them when dir permissions change. Hardlinks are doable but the dir permissions thing gets interesting when a file's accessible from two separate paths.
This works really nicely if you want to do some kind of "fuzzy" name matching -- correcting typos, case insensitivity, or whatever. It could be generalised to having a database-style index across a filesystem for fast access.
Is there any mileage in using a slab allocator for handing out space in a filesystem? For a reasonably-constant filesystem, you could easily tune it based on the content beforehand.