This is the current official layout, first published by Walter in NewsDmD, Oct 29, 2003: http://www.digitalmars.com/d/archives/18684.html
- Contains the 'standard' modules that will be available on all implementations of D. Emphasis in this package will be on reliability, stability, and portability. std as a name has the advantage of being used in C++ to specify the standard library, and so is familiar and highly unlikely to conflict with common variable names.
- Contains D interfaces to standard C library functions, like std.c.stdio, std.c.stdlib, std.c.math.
- Access to platform specific functionality.
- Specific to win32 and win64 operating systems. (win64 is coming, so calling it 'win32' would be a mistake.) The excellent point was raised about operating system specific code not being in the std tree as it evolves constantly. I understand that point, but operating systems evolve by adding API's, not subtracting them. So any windows package should continue to work as long as there's a windows operating system.
- Specific to linux operating systems. (StdOsLinuxComments)
- Where the various TypeInfo? implementations go.
- Internal magic implementation-specific runtime support code.
- There are lots of 'other' modules for D, and right now there is no organized way to deal with them. There needs to be a place for them. The etc heirarchy will mirror the standard one, i.e. there will be etc.c, etc.os.windows, ... These will not be official parts of D nor will they be standardized. However, candidates for standardization will be drawn from etc. etc is the place for not-quite-there-yet-but-still-useful modules.
Major packages, such as a D gui, will merit their own toplevel name. Vendor specific modules will use a toplevel name being the trademarked vendor name. For example, vendor BrandX? would put their vendor specific packages under the toplevel name brandx.
std.os.windows and std.os.linux were then moved to std.windows and std.linux, it seems...