DIP16: Transparently substitute module with package

[Nick Sabalausky]

My comments:

1. My first impression was that using "foo/bar/package.d" instead of 
"foo/bar.d" seemed a bit odd and messy. But I realize now that cleverly 
solves the issue where "foo/bar.d" would be considered to be inside a 
different package from "foo/bar/*.d". So I like that. Personally, I think I 
would have gone with "foo/bar/_.d" as that sorts much, much better, but 
naming debates can go on forever, and I can live with "package.d"

2. I don't understand any of this:

-------------------------------------------
When looking up the symbol "foo.bar.baz", currently an exact match is 
needed. However. when looking up ".baz" or simply "baz", a flexible lookup 
is used that has many advantages (less verbose, hijacking detection etc). 
Therefore we think similar flexibility should be imparted to "foo.bar.baz", 
as follows:

If a qualified symbol "foo.bar.baz" appears in code, the compiler considers 
"foo.bar" a prefix that sets the starting point of the lookup, and then 
proceeds with looking up "baz" from that starting point. That means a 
program that imports std.algorithm may use "std.sort" for the symbol 
"std.algorithm.sort".
-------------------------------------------

I *do* understand "a program that imports std.algorithm may use "std.sort" 
for the symbol 'std.algorithm.sort'", and I think that's a good idea. It 
solves a problem I hadn't even thought of. But I don't understand that stuff 
I quoted above. Perhaps you could reword/clarify?

3. Other than that stuff, I'm very much in favor of this. I'll have some of 
that!