I have attached a series of patches with (hopefully) provide more robust fix for this issue, against the Python 3.3 branch.  It handles both bytes and str objects, paths that do not actually exist on the filesystem, and removal of the '\\?\' prefix returned by _getfinalpathname, unless the supplied path had that prefix already.  A couple of the patches contain some separate infrastructure that could hopefully be used to simplify some of the other Windows code in posixmodule.c (One immediate possibility would be to combine the code provided in these patches with the symbolic-link resolution code in the Windows stat functions - there is quite a bit of duplication there that could be eliminated.)

One thing these patches do not address is resolving a broken symbolic link.  The Windows API function GetFinalPathNameByHandle does not handle this case (because CreateFile cannot be used to get a handle if the symbolic link is broken).  This functionality could be implemented by manually following the reparse points, but that would basically require reimplementing GetFinalPathNameByHandle.

Finally, this patch could be fairly easily backported to Python 3.2, but that shouldn't be done without careful consideration.  It changes the return value from os.path.realpath on Windows even when there are no symbolic links in the path (the returned value will have the actual casing as stored on the filesystem, instead of the casing supplied by the user).  I don't think it should be backported to Python 2.7, because that version, like all Python versions before Python 3.2 are unaware of symbolic links on Windows (e.g. lexists is the same function as exists).

The patches were generated using git (I use git-hg) - if that format is a problem, let me know and I can regenerate them.