Removing support for %HOME% has suddenly broken many programs. If people don't like it, we can consider deprecating it in some future version of GHC, but for now it should put back. I would say it is quite ironic that some people are arguing against this by saying that it will lead to more bug reports. It is *not* "trivial to wrap the function in question", and it is not "more correct". The current behavior is not more WIndows native - it is arguably much worse. The %HOMEPATH% variable should definitely not be used. The folder that it points to is not a "home directory" and should not be used that way. But if there is no other way to provide a value for getHomeDirectory, I guess that is still better than throwing a run-time exception, but at least obtain the path in a somewhat Windows-friendly way by using the API properly. It is just not true that using %HOME% creates problems. This is a widespread convention, in active use. Admittedly ad-hoc, but it works. Does anyone know of even a single incident in which this created a problem? Better native Windows integration is definitely an important goal. The whole idea of a ".ghci" file is very Unixy, for example. There is a lot of work to be done in this direction. Pulling the rug out from under %HOME% without providing a reasonable alternative is not the way to begin. By "reasonable alternative", I mean a way that users can configure GHC's notion of "home directory" at run-time on Windows. Truthfully, I don't think this should be the first priority for better Windows integration. Wouldn't our time be better spent on Visual Studio integration and WinAPI support? Not to mention .NET... Thanks, Yitz