Issue: DEFPACKAGE (Version 7)

[Jon L White <jonl@lucid.com>]

re: My first reaction is that the only thing that should be undefined is if
    the new definition specifies a different :USE list.  The rest of the
    possible conflicts could be handled using the normal error handling of
    the package modification functions.

The term isn't "conflicts", but "variances" between the first definition
and the second.  The :use list isn't the only significant variance;
consider the set of :export'd symbols.

One of the most common recipes for disaster is to have differing EXPORTs
in two package definitions, and then to load a file which was compiled in
one of these two enviroments into a "runtime" image that has the other
environment.  The file being loaded may expect to inherit some symbols
(due to their being EXPORT'd from a "used" package at compile time); but 
failing to inherit at "run time", it will create a Doppelganger in the 
current package

Virtually any difference *can* be made to be critical, due to the fact
that the package system is a global database in a flat namespace (there
is no "context" for FIND-PACKAGE).  Leaving it undefined as to how to 
handle varying package re-definitions allows the implementations to
experiment with helpful warnings, recovery stratagies, etc.


-- JonL --


P.S. For many years now, I've  used the term "Doppelganger" to refer to
     a symbol of the same print-name, but not EQ to the one desired.
     Sooner or later, a Doppelganger _may_ cause a name-conflict error;
     but often it is only after pointers to it have been read-in and
     distributed throughout the whole system (makeing it almost 
     impossible to correct the problem).  Often the Doppelganger just
     quitely masquarades as the real thing, and you get "unbound
     function" errors rather than package name conflicts.