Your quotation from MS is interesting, but I think it does not explain the issue, for two reason:

1. If the timestamp would be updated after the file handle is closed, a DEL followed by an "ECHO ...>FILE" should result in a correct time stamp.
2. If the effect would be due to an 1-hour-caching delay, the effect should be gone after one hour, but it isn't. Moreover, it even survives a reboot.

What is likely correct is the observation, that this is NTFS specific. On a networked drive, the effect does not occur.

It is also not specific to Windows XP. We can reproduce it now also on Windows 7 without problems.

I think we just have to accept the fact that, on Windows, creating a file doesn't mean that the ctime is set to the creatin time; the ctime may be a much older timestamp, if the file system is NTFS and a file of the same name had existed some arbitrary time in the past.