Lots of DIP discussions this week and I will write a little about code organization.
See more at the announce forum.
Short thing here: I like Walter's proposal because it sounds like it would just work. I know there is some worry about names being a breaking code change, but meh, you should think about your names anyway because it is in the documentation!
Many of you know that I tend to use fairly large code files. I like to group everything needed for a higher level piece of functionality together, so the whole thing can be understood by jumping around the file. Any time I have to jump around files to make sense of what something is doing, I get annoyed.
Of course, a lot of people feel the opposite: they want each chunk that can be discrete to be put in its own file, often with deep directory hierarchies too.
Well, let me suggest a new idea: we're all wrong. I'd argue that when actually working with code, the files should be ignored. Instead, we should be navigating functions, classes, etc. Rely on stuff like "go to definition" instead of "open file X". Instead of (not in addition to, instead of!) displaying a filesystem tree, display a definition tree with fuzzy search. The actual file layout should only become an issue when interoperating with more generic systems, and even then you might like "copy the source of function X into an email" rather than "attach file Y".