On Posix, it is documented that setting PATH to the empty string is equivalent to not setting PATH at all, which is an exception to the rule that in a string like "/bin::/usr/bin" the empty string in the middle gets interpreted as ".".
PYTHONPATH does not have this exception: an empty PYTHONPATH is interpreted as equivalent to ".".
This difference is not documented. This is a detail, but a possible source of confusion, so I'm reporting it here.
How to reproduce:
file x/x.py: "import z"
file z.py: "print(42)"
The following two lines behave differently (Bash syntax):
PYTHONPATH= python x/x.py
unset PYTHONPATH && python x/x.py
For comparison, if "./foo" is an executable, the following two lines behave identically (neither finds "./foo"):
PATH= foo
unset PATH && foo

> Given how confusing it seems, perhaps we should change it to
> adopt a PATH-like behaviour.
Wouldn't that introduce a backward-compatibility issue? FWIW, otherwise I agree that it makes a lot of sense to conform to the same behavior as PATH.

Hmm. Although that argues that the original behavior was in fact correct. At least, the behavior of bash and zsh for me is that
PATH= foo
finds foo if it is in the local directory, contradicting the claim made in the original post.

Uh, confusion. Indeed, "PATH= foo" finds foo in the current directory on bash. I'm not sure how I ran the original example. It seems that a default PATH is used, which includes at least "/bin" and ".".
The point I was making in the original post is still valid: "PATH= foo" appears to behave identically to "unset PATH && foo" in all cases I tried so far. For example, for me both work with some local executable or with "ls" (which is in /bin), and neither works with "which" (which is in /usr/bin).

I don't think bin is included:
> PATH= gzip
bash: gzip: No such file or directory
But you are right...unset seems to be equivalent to PATH=
I could have sworn it acted different when I tried it, but I just ran it again and it it acted the same, which makes sense.
So given that I agree that the fix is good. And further fixing is not :).

Grrr, ok, I have an "alias ls='/bin/ls'". It seems that both "PATH=" and "unset PATH" are equivalent to "PATH=.". This is behavior that we cannot add to PYTHONPATH, I fear, because so far "." is not implicitly included if PYTHONPATH is not set. Or if we do it's a big change, not just an internal fix...