On Mon, Jul 8, 2024 at 9:05 PM Scott L. Burson <Scott@sympoiesis.com> wrote:

> 2.2: The strongest point I want to make here is that a correctable error should be signalled whenever a package becomes fully shadowed by another package (all of its global names are shadowed), with a restart that requests a new local nickname for the shadowed package in the shadowing package(s).  We want to alert the user to the situation, and strongly encourage them to add a new nickname (global or local) in the relevant source file so as to make the fully shadowed package accessible again.  Meanwhile, we supply the restart to make it easy to remove the shadowing in the current session.

I think signalling an error at the point where a package becomes
completely shadowed is a bad idea . It destroys the locality of the
local nicknames and brings us back to the problem where you can't load
two systems at the same time because they happened to both want to use
the same convenient name. Arguably one of them has a bad name, and
should have other names, but lots of CL code is old and un- or
under-maintained, and we shouldn't be annoying users about them just
for a very rare edge case.

>  In my view, the purpose of local nicknames is to shorten frequently typed package prefixes.  Using them for anything else seems potentially unsafe.

Another intended use case was people who want to substitute one
package for another without having to change the code (either picking
from multiple implementations depending on requirements, or replacing
an old lib with a compatibility layer, etc). I've seen people describe
doing that with :USE, and package local nicknames should support it as
well, and more safely in cases where any of those packages might
change over time.