Yes, folder hierarchies can be one reasonable way to group related code... but they're still file-based, and they still assume that you can find The One Right Taxonomy to describe your entire codebase. This is a dumb assumption and we should make it go away.
Right now, the Epoch IDE is set up to store code in... yes, sigh, flat files. However, files mean nothing - they are all lumped together equally during compilation. There is no implicit file-to-module relationship like in virtually every other language ever.
As an experiment, I'm thinking about removing this from the IDE entirely. I want to see what it would feel like to work on a large project - like the Epoch compiler, or the Era IDE itself - without the restriction of thinking in terms of files.
I can hear the protests already... how does one find code if there is no file grouping?
Well, one option - and certainly not the only or "best" option - is tagging. Each function or other top-level construct (like a structure or type definition) appears in its own universe by default. You can join this universe into other universes to make pockets of code, simply by tagging a function with some label. The IDE then displays a list of labels, and you can open them up as if the tagged content existed inside a single file. Behind the scenes, each "island" of code is a single file on disk.
I kind of like this for the sake of version control, because it allows naive version control software (i.e. basically all of it) to actually do function-level histories. I kind of also hate it because it means a large project may consist of tens of thousands of files when a few dozen would suffice.
I'll try and think of other options, but I'm open to suggestions. Basically I want to make the code-to-file mapping a little more modern and a little less stuck in 1970.
This might interest you http://blog.datomic.com/2012/10/codeq.html