SHARPSIGN-PLUS-MINUS-PACKAGE
In some systems, the current package is used. Since there is no wording in CLtL to the contrary, it's reasonable to assume that this would be done, but a consequence of this is that you must be much more sensitive to the package you're in at any given time when using #+ or #- even for system-provided features. (This is a problem if the LISP package can contain only the symbols in CLtL because system-provided features will likely not have the names of symbols on LISP and hence will require package prefixes. Having a symbol named LISP:SYMBOLICS or LISP:LUCID would not be possible, so something like #+Symbolics would not be possible; you'd have to write #+SYSTEM:SYMBOLICS or some such, which might get a read error in a non-Symbolics implementation that didn't export SYMBOLICS from SYSTEM...)
In some systems, a canonical package (such as KEYWORD) is used. This means that package prefixes are rarely necessary in sharpsign conditionals for system-provided features regardless of the current package or restrictions about what may be in LISP. (For example, the KEYWORD package can have any symbol so it's not a problem to push :SYMBOLICS or :LUCID on *FEATURES*).
This has implications about what goes on the *FEATURES* list (p. 448).
Symbols on *FEATURES* may be in any package but that in practice they will mostly be on the keyword package because that's the package #+/#- uses by default. If symbols in a package other than keyword appear on *FEATURES*, they will be seen by #+/#- only if marked by explicit package prefixes in the written feature-spec.
Clarify that the package of the IEEE-FLOATING-POINT symbol mentioned on p. 448 is KEYWORD.
*FEATURES* directly.*PACKAGE* while reading feature specs and others do not.*FEATURES* in different ways for different systems.*FEATURES* directly may require editing.
It might be reasonable to suggest that only vendors should add keyword symbols to the *FEATURES* list, and that users should add features on their personal packages so that collisions due to user applications were less likely. This idea might be a subject of controversy though, so is not part of this proposal.
It would be useful to create a non-binding registry of feature names (and package names) already in use, so that Lisp implementors could pick otherwise unused feature names, and users who wanted to write portable code could know what feature names were preferred.