Module Clarification

[Jonathan Marler via Digitalmars-d-learn]

On Thursday, 22 September 2016 at 11:40:17 UTC, Steven 
Schveighoffer wrote:
> This should be fine. x/package.d is equivalent to module x.

Ok, it looks like no-one thought what I was doing was off-base. I 
guess this brings up another question.  Why doesn't the compiler 
support modules in a hierarchy?

foo.d
foo/bar.d

The only reason I can see is that you would have to setup some 
rules on how to handle it when you have both a module file, and a 
package.d file in a directory with the same name:

foo.d
foo/package.d // huh? error?

Actually, the more I think about it, I'm not sure there's a good 
reason for the "package.d" semantics to exist.  I guess it 
establishes a pattern when people would like to combine smaller 
modules into one public module, but it doesn't have to be used 
that way.  The opposite is true that you could use a normal 
module (not a package.d module) to publicly import smaller 
modules:

Instead of:
foo/package.d // publically imports fooPart1 and fooPart2
foo/fooPart1.d
foo/fooPart2.d

What was wrong with:
foo.d // still publically imports fooPart1 and fooPart2
foo/fooPart1.d
foo/fooPart2.d

If the package.d file didn't exist, then I don't think there 
would be any problem with hierarchical modules.  Is this the 
right conclusion?  Was package.d a mistake?  Maybe the reasoning 
is that D doesn't really like hierarchical modules, so creating 
them should look a bit odd?

foo/package.d
foo/bar/package.d
foo/bar/baz/package.d