issue IN-PACKAGE-FUNCTIONALITY, version 5

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

I fully agree with the first part of this proposal (remove IN-PACKAGE,
add WITHIN-PACKAGE).  Like JonL, I disagree with the second part (what
COMPILE-FILE does with symbols).  Part of the problem is it uses the
words "interned" and "occupied" which are not given precise definitions.
Here is a suggested recasting of that paragraph of your proposal using
the words defined at the beginning of the chapter:

    When a compiled file is loaded, the interned symbols it references
    are found by the following procedure.  The rules are applied in the
    order listed and only the first applicable rule has any effect.

    (1) The distinguished empty list symbol NIL retains its identity.
    
    (2) Any symbol accessible at compile time in the package that is the
    value of *PACKAGE* is found by calling INTERN at load time with one
    argument, the name of the symbol.

    (3) A keyword symbol is found by finding or creating a keyword
    symbol with the same name.
    
    (4) A symbol that at compile time is an external symbol of its home
    package is found at load time by finding the package with the same
    name as the compile-time home package, and then finding an exported
    symbol of that package with the same name as the compile-time
    symbol.  If no such package exists, no such symbol exists, or the
    symbol is not exported, an error is signalled.

    (5) Any other symbol is found by calling INTERN at load time with
    two arguments, the name of the symbol and the package with the same
    name as the compile-time symbol's home package.  If no such package
    exists, an error is signalled.

The goal of this procedure is for each symbol reference to be
resolved to the same symbol when a compiled file is loaded as when
the source file is loaded directly with LOAD.  It is possible to
create package structures that make that impossible; for example, it
is possible for a symbol to be inaccessible from its own home
package.  A conforming program cannot depend on any symbol
resolution behavior that is not provided by the above five rules.

If any top level form in a compiled file changes the value of
*PACKAGE*, other than a WITHIN-PACKAGE appearing as the first
effective top level form in the file, the results are unspecified.
[What I mean by "effective top level form" is to include x in
constructs like (PROGN x ...) and macros that expand into x.  Do you
compiler people have a name for this?  That is, a WITHIN-PACKAGE
must be the first top level form that has any effect.]

Perhaps this should be a separate proposal from IN-PACKAGE-FUNCTIONALITY?