I think it's not a mistake, it's the only sane thing to do in the current tooling ecosystem. Try e.g. writing a correct Makefile without a 1:1 correspondence, and you will end up with either something shell-script like or miss some dependencies. As an exercise, try something like this for e.g. Java where there is no 1:1 correspondence between the source files and the build artifacts. OK, the compiler knows the dependencies when trying to compile things, but that is basically the only tool which is 100% correct. But this doesn't really help when writing Makefiles, because you can't even see the e.g. dependencies of a .class file (the compiler inlines e.g. "static final int"s without a trace where they came from). The situation in the Haskell world is not much different: Yes, "ghc --make" knows how to do its task, but integrating this into a project where Haskell compilation is only a part is not easy or ends up in something non-declarative shell-script-like.

To be honest: I can't really understand all of this discussion. It would be great if the status quo of a mapping between hierarchical names and a directory hierarchy would end up in a spec, so it is *the* way to do it. Doing things in exactly one way frees up the mind from figuring out useless details, in this case based only on personal taste. I haven't heard a single compelling *technical* reason for doing it differently up to now...