Hans Aberg writes:
 >   Then one may discuss how long the long names should be: Certainly, one
 > cannot diminish the number of module separators (like "/" in these
 > discussions), because they tell something about the logical structure. But
 > it is possible to let the module named "environment" have names starting
 > "envir/" by simply letting the command \environment/ expand
 > \environment/<command name> to \envir/<command name>. But then the module
 > name "envir" cannot be used.

Aha, yes, I'm sure this is something else my stomach was thinking
about . . . :-)  A renaming like this may inadvertently conflict with
something else in the system.  Perhaps the way around this is to
enforce the use of a \newshortcut, which does checking a là
\newcommand.

 >   Similarly, the module named "environment" should not be required be in a
 > file named like that; if one wants to specify a special file or file
 > position, there should be command doing this. (Such command could be made
 > to be platform independent between say UNIX, MacOS and MSOS if there is
 > another command telling which platform it is.)

Implementors might take a leaf out of web2c's book - the
texfonts.map file.  (See the kpathsea documentation.)

 >   So here, they way I see it, the long names (1) are only used really in
 > order to keep the code straight and avoid code clashes. The user
 > (preferably also developers) should only need to use short names by various
 > of simplifying schemes; this is (2) then. But non-local names should expand
 > to long names.

Hmm . . . this is the exact opposite of what I was suggesting.
Developers use the long names to make it easier to write; these get
translated by docstrip/doc.sty into short names to minimize format
size and control sequence usage.  Still no word from the Team as to
whether this matters for LaTeX3.

 >   When developing the simplifying schemes (2), I do not know how to do it
 > for the simple reason that TeX is too tricky to program. One can simply not
 > invent some nice general schemes, then sit down, program it in TeX and hope
 > it is going to work. Generalities is evidently not Knuth's strong side.

I have some ideas about how to implement the suggestions in my earlier
e-mail.  I don't think it would be too hard; it's primarily a matter of
making sure that implementors and package-writers keep to the `rules'
(i.e. like always using \newcommand instead of \def).

 >   So (2) must be developed together with (1), so that the two cooperate.

Indeed.