playing with the idea of splitting files, mapping their tree structure to the filesystem, I came to the conclusion that the opposite of the pattern could be more than useful: aggregate filesystem.

What and Why? Just simply imagine a large project with hundreds of files, where you would have to do a huge huge huge huge refactoring that would affect more than 50% of files. (renaming for example). Opening each file is out of question. You could write some sed scripts to do the job. But why? Why you would not be able to open all the files in vi or you favourite editor, first do some analysis by searching for occurrences, then mass replace, etc, etc.

The aggregate filesystem should have some configuration file that would define what is aggregated by listing the files or defining rules (regular expressions for example, globing) about what kind of files to be included (for example all files under a directory). You would end up with a huge file that would be composed by all the files (in random order). End of files of each original file would be marked with a special line, I will call it pivot line. These pivot lines would unambiguously identify the end of file. Removing such a line would mean that the content would flow to the file that follows. The pivot line would also contain the full path of the original file.

When you open an aggregate file and start to read it the aggregate fs would open all the aggregated files (or eventually define other strategies). If you would read the file, the aggregate fs would read one by one all the aggregated files. When saving an aggregated file, the aggregate fs would save each part of the content to the original file indicated by the pivot line.

Such pivot line would also help to create commands inside your editor that would have eventually affect on the original file. For example open the original file.

Such a filesystem could be implemented both in kernel and userspace with fuse.