> This changes the documented behavior of a commonly used function.

Right. If this change is considered too big for 2.6, may be it can be applied to 3.0? 

> FWIW:  MoveFileEx() with MOVEFILE_COPY_ALLOWED isn't transactionally
> isolated.  Other processes can see the new file being created, and watch
> its size increase, while the old one still exists.  It isn't atomic,
> either: in certain error cases, e.g. if the process's permission to write
> the target file is suddenly revoked, it will fail after making changes to
> the filesystem.

True. But isn't this the case with MoveFile() too? I couldn't find any clear mention about transactional behaviour of either MoveFile() or MoveFileEx(). Same goes for atomicity.

> Also-- it looks like the test leaves one of the temp files lying around!

I can take care of that. While I think about it, it is perhaps not correct for this test function to be in Win32ErrorTests.