The path to modules is set incorrectly for run-in-place

[Stephen J. Turnbull]

In an installed XEmacs, modules are installed in a single directory,
which is architecture-specific, of course.  In run-in-place, however,
built modules just live under "modules", and normally in
subdirectories for each modules.  The find-paths.el and setup-paths.el
mechanisms don't seem to be able to handle either of these differences
(setup-paths doesn't recurse into subdirectories when looking for
modules, and find-paths assumes that the architecture string will be
part of the directory name in an architecture-specific directory,
AFAICS).  (But then, how does an in-place XEmacs find lib-src?  I'm
confused.)

As a sort of contrapositive to the startup.el hoses load-path thread,
this means that a module can be loaded into an XEmacs that isn't
configured for it.

Mike, I think Aidan's right.  There is no reason other than somebody's
unwillingness to set an environment variable for looking outside the
source tree for core code in a run-in-place XEmacs.  Package lisp will
live in the package tree, and modules built outside of the source tree
will live in site-modules.  If you really know what you're doing, you
can set environment variables to point to previous builds for the same
version and architecture, but it's just too risky to do that by
default.