I hope you take critism as an indication that people are really interested in your language...

> #  The wchar type can be either 2 or 4 bytes wide in current implementations; future implementations can increase the size further.

The author of C regretted that he did not make his integral datatypes well defined, and D may repeat C's history with wchar.  I suggest using char16 and char32 instead.  If I'm writing for Windows, I use char16 for win32 API calls and if I'm writing for linux, I would use char32 for linux API calls.

Will D have two sets of code for handling strings? Yes, but D will have this anyways with ports for the two operating systems.

Libraries that have wchars as their parameter lists will not know the size
without testing them -- something that is better done with overloading
(method(char16[] str) and method(char32[] str)).

As it is now, wchar forces us (library programmers) to think about the wchar datatype.  D might as well make it more explicit.