I get the sequence of events and that there is nothing to "restore to".
I would characterize the "bug" as a zillion completion function authors
(like the git branch example that made me discover this) control their
code, not me. These authors do not know/expect their `local` will
clobber global state (which in this case is not a global var).
So, your idea 3. creates a burden to submit patches to any that happen
to use "maybe colliding" names which seems unrealistic. Your idea 2
doesn't recognize any value to keeping $<TAB> and ~<TAB> namespaces at
all separated. And idea 1 just denies value of the AutoNameDir (A_N_D)
feature itself. So, in short, sure for a multi-way interaction problem
you can just not engage one of the legs of the interaction as a "fix",
but this just re-states the problem (perhaps more clearly, thanks!).
I should also have said that, while you can always get lucky or with
foresight be smarter, it can take a while to track down the issue. Do a
hash -d in RC files, interact a long time, engage some completion for an
obscure subcmd, a long time later notice that your hash-d was removed.
Even once you know of "a problem" you can code up some precmd/preexec
to trap it, but it might still take quite a while to engage again the
completer function or subfunction that causes trouble. It may not even
be in your shell history which is, after all, not a keystroke history.
I did not audit all the completers that ship with Zsh, but it would be
surprising if there aren't quite a few similar problems.
My feeling is that A_N_D is an interactive top-level feature (Philippe's
reply helped me realize how much, THANK YOU - but docs for the setopt
also reflect this as prompts & completion are both interactive, top-level
ideas). This suggests its utility within shell functions is minimal.
(Your 1 suggests you think total utility is negligible!).
So, blocking local sets from doing any damage to the hash-d namespace
seems an ok answer. This would probably bother no one using A_N_D at
the top-level for ancient convention leveraging automagic FOOROOT
prompt abbreviation with the matching reference syntax, `ls ~BAR_HOME`.
Maybe most briefly, the doc fix for A_N_D setopt could be as small as
"Any parameter that" -> "Any global parameter that". Would anyone
oppose that sort of fix? Do people use A_N_D within functions? Would
it cause other notable problems? Thanks for feedback on this more
concrete idea for a fix.