>This certainly looks plausible.  I can't offhand think of a reason why a
>hashed command would begin with a "/"; it's just asking for trouble.

Cool.  I think stricter/cleaner cmdnamtab is safer long-term.  Not sure
any users will complain about 'hash' built-in no longer saving absolute
keys which is a consequence of your preferred resolution, but that's
only likely to be short-term, if it exists at all.

You likely want to document that in the man page or at least release
notes so that any 'hash' users aren't mystified.  Also, you may want
to double check other possible ways cmdnamtab can be poisoned.  greping
for addnode.cmdname, I think the only other spot is Modules/parameter.c
but parameter names cannot have dots and slashes anyway.

I haven't analyzed it -- the code is so twisty and FS state dependence
as well as all the setopt stuff is a lot of cases -- but it's at least
conceivable that user-inserted *relative* paths in cmdnamtab can break
something (maybe a feature other than AUTOCD or some future feature).
There may be no good reason to have explicitly relative paths starting
with "./" or "../" in there either.  You may also want to expand your
preferred solution to cover those.  PATH-relative entries can make
sense.  Eg., mh/inc for those old school enough to recall /usr/bin/mh
installations.

So, I'd stop short of a "block *any* '/' in cmdnamtab keys" rule.
Testing just the start of the string is faster anyway.  Presently,
neither the explicitly relative (which don't make sense to cache) nor
PATH-relative entries (which do make sense to cache) get in cmdnamtab
automatically unless I'm missing something.  They can be put manually
via 'hash', though, and PATH-relative profitably so (a dubiously small
profit, but still).  If they do cause trouble it's "likely" users know
they did it by hacking search with 'hash'..Probably very rare if it's
even a problem at all.  All famous last words, though.  Some under-
the-covers package might do it for them.

Indeed, running whence on absolute paths has to be rare, too.  I only
noticed it recently using zsh-syntax-highlighting which broke AUTOCD on
just a couple root dirents..mysteriously at first.  I didn't realize it
was z-sy-h for a while.  Then it took a short while to isolate it to
just entries in my $PATH.  Then I just disabled z-sy-h for *just* long
enough to forget why I disabled it.  Re-trying z-sy-h a few days ago
reminded me.  I figured I should report this time since last time I
forgot.  Matthew Martin quickly reduced the misbehavior to whence with
Daniel doing an easy subshell fix to avoid poisoning longer-term state.

Curious just how long this bug lurked, I tested old versions of Zsh.
I had to go all the way back to zsh2.1 from circa 1993 to find a
version *without* this bug.  zsh2.0 also worked.  I think 2.0 may have
been the first release with AUTOCD.  At least zsh-1.0 didn't have it.
So, well, it worked for a little while, anyway. ;-)