I think I've found all the instances of this bug: files.el (already
fixed) and ls-lisp.el (already identified) and tramp-sh.el. I attached
recipes to reproduce against master @
0646c6817139aa905a2f6079fdc82eb4be944de0.  The preceding libraries are
the 3 implementations of insert-directory I found. From what I can
tell, these are usually expected to be called from dired and
list-directory, the former of which ensures default-directory is set
as expected before calling insert-directory, and the latter of which
does not, which is where this was initially reported.

Testing these in a real scenario doesn't show any other interesting
behaviors.  Invoking via dired always does the correct thing, and
invoking via list-directory, or calling insert-directory directly,
always does the wrong thing (i.e. shows the free space of
default-directory instead of the insert-directory file arg) when the
default-directory does not match the file argument. This is true when
either/both of the insert-directory arg or the default-directory are
standard paths or tramp paths.

I think the fixes for the remaining two libraries are going to be as
simple as the previous fix: pass file-system-info the actual file arg
instead of ".". While ensuring default-directory is set as we want
seems to allow "." to work correctly, I haven't found a concrete
advantage to that over just passing the file arg through. (e.g. some
path expansion that only file-system-info can do.) I'm not very
confident that I understand that space fully, though.

Though the fixes may be simple, the tests for even one of the
libraries would be large enough to require my completed copyright
assignment, which is in progress now. The approach I have working now
is just to stub out file-system-info to simulate returning different
free space for different paths and verifying
list-directory/insert-directory shows the matching free space. Anybody
see any big problems with that or have other suggestions?  I also
don't want to duplicate that test for each of the 3 libraries, but I
haven't found a good way to share test utilities like that yet.