Issue: DEFPACKAGE (Version 7)

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

re: . . .  How about this as an
    alternative to "at most the original package will be updated":
    "however, no objects other than the original package will be
    modified as a result."

Doesn't work -- by performing the newer definition, you may require links
to be modified in other packages' used-by lists.  

If this really is an insoluable problem for you, and if other people
also feel so uncomfortable with it, then maybe we should just flush
the whole phrase; after all, the primary things we want to say are that:
  (1) you don't change the name-to-package mapping, and
  (2) you *might* alter the existing package [then again, you might not].



re: . . . Kathy's proposal for
    the new classification system of error situations includes a
    description of this case.  As I said, I don't remember the actual
    terminology she used for this case (I suggested "undefined but
    benign", but she rejected it), but the description was like what you
    described.

Hmmm, well I'm not familiar with this yet newer error terminology proposal.


-- JonL --