You right, problem is not in os.unlink (Windows call DeleteFile) itself.

I have TortoiseSVN (very popular Explorer extension to work with 
Subversion) installed. 
This tool run TSVNCache.exe process to update own data in background.
TSVNCache.exe receive NotifyChangeDirectory events for svn checkout 
folders. 
support.TESTFN is tempfile name in current working directory. If I try 
to run unittests from some folder from python checkout TSVNCache.exe get 
change notify and analyze it.

So, sometimes I can see race condition:
- python: os.unlink(file)
- TSVNCache.exe: get change event
- TSVNCache.exe: query changes
- python: open(file) - oops, TSVNCache.exe still processing notification 
and lock deleted file by holding opened handles to it.
According to MSDN for DeleteFile function:
The DeleteFile function marks a file for deletion on close. Therefore, 
the file deletion does not occur until the last handle to the file is 
closed. Subsequent calls to CreateFile to open the file fail with 
ERROR_ACCESS_DENIED.
We get exactly same.
- TSVNCache.exe finish of change update and release handle. File is 
actually deleted.

I see this situation in sysinternals Process Monitor tool.
Probability of race condition is tiny but non-zero. Intensive 
create/drop/create again sequences can catch this one.