To do this, we'd have to drag this support all the way down to the
lowest level where we pass file names to the OS APIs. And then we'd
have to disallow root directories of one letter, like C:/c, which are
entirely legitimate. All that just to handle the few commands during
the build process that need it. I find this solution even more ugly
than the unmsys--file-name gork.
I'm afraid I don't understand your point here. To reiterate, the current problem is that Emacs does not know how to treat "/C" in the beginning, therefore it assumes that the path given does not have a drive letter, so it add "c:" in front of the given path as a wild guess. The only thing that I propose to change in that logic is to allow paths which contain a slash + a single letter in the beginning, e.g. "/C", so that when Emacs sees it, it simply converts that to "C:" and passes further to old logic of path manipulation. In other words, nothing has to be changed to the lowest level as you say. My change involves one `if' statement or so in the very beginning of the path processing. Furthermore, I don't get it why you would have to disallow "C:/c"? If somebody passes "C:/c" then it's perfectly valid Windows path. If somebody passes "/C/c", then according my proposal it will be converted to "C:/c" and then processed further.