I see now. It's not a problem with the junction. In the stat implementation, after verifying that the directory or file is a reparse point, it opens it again without FILE_FLAG_OPEN_REPARSE_POINT, in order to open the target instead of the link. I don't understand why it doesn't use this handle to call GetFileInformationByHandle again, this time on the target. Instead it calls get_target_path in order to recursively call stat on the target path. 

To get the target path it calls GetFinalPathNameByHandle and requests the DOS name, which requires a drive letter. At this point Windows has a native NT path (e.g. \Device\ImDisk0\python-default\PCBuild), so it has to query the mountpoint manager to get the DOS drive letter mapping (i.e. \Device\ImDisk0 => P:). This is done by opening a handle for \\.\MountPointManager and calling DeviceIoControl to query the drive letter. This is the call that fails with ERROR_INVALID_FUNCTION (1). Indeed, you'll get the same error if you try calling os.path._getfinalpathname on any directory or file on this drive.

It's probably the case that the ImDisk driver doesn't support the mountpoint manager at all. For example, in the \Global?? object directory there's no GUID symbolic link assigned to the device, which is normally assigned by the mountpoint manager. Also, mountvol.exe doesn't list the ImDisk drive.