So one consequence of this is that every time a new release of flit (for example) adds a new dependency on X, or one of flit's dependencies adds a new dependency on X, then this is technically a backwards incompatible change, because any existing packages that use flit and happen to have a top level directory named X will stop working.
I guess the most obvious example of when this would occur is: suppose click switches to using flit for builds, and then flit switches to using click for command line parsing. Now there's a bit of a chicken and egg problem where 'pip install click' will end up importing flit with the click source tree on the path, and this tree of course contains a directory named 'click', so unless special measures are taken flit will end up importing the code it's trying to build.
But of course this can happen for lots of reasons; most packages have names that you wouldn't expect to randomly encounter at the root of a source tree very often, but with 100,000+ packages on pypi I expect it will happen eventually.
This doesn't happen with setuptools because setuptools traditionally has few or no dependencies, but obviously we're changing that; the whole idea here is that now your build system has full access to pypi.
Anyway, when this happens, what's the recommended mitigation? Should flit and other backends take special measures to delay imports until after their hooks are called and they have a chance to play games with sys.path? Should we put the source tree at the end of sys.path instead of the beginning, so that site-packages masks the source tree instead of vice-versa? That would be different from what people are used to from setup.py and other scripts, and seems like it might cause its own problems, but maybe it's better?
Or am I worrying about a non-issue and it's fine if flit imports click from the source tree?