Issue 25994 added support for the context-manager protocol and close() method in 3.6. So it's at least much easier to ensure that the handle gets closed. 

The documentation of scandir() links to WinAPI FindFirstFile and FindNextFile, which at least mentions the "search handle". It's not made explicit that this encapsulates a handle for a kernel file object, nor are the operations (e.g. move, rename, delete) discussed that are allowed directly on the directory. Similarly, the directory stream that's returned by and used by POSIX opendir() and readdir() may or may not encapsulate a file descriptor. 

I don't think Python's documentation is the best place to discuss platform-specific implementation details in most cases. Exceptions should be made in some cases, but I don't think this is one of them because I can't even link to a document about the implementation details of FindNextFile. At a lower level I can link to documents about the NtQueryDirectoryFile[Ex] system call, but that's not much help in terms of officially documenting what FindNextFile does. Microsoft prefers to keep the Windows API details opaque, which gives them wiggle room.

FYI, in Windows 10, deleting files and directories now tries a POSIX delete (if supported by the filesystem) that immediately unlinks the name as soon as the handle that's used to perform the delete is closed, such as the handle that's opened to implement DeleteFile (os.unlink) and RemoveDirectory (os.rmdir). NTFS supports this feature by moving the file/directory to a reserved "\$Extend\$Deleted" directory:

    >>> os.mkdir('spam')
    >>> h = win32file.CreateFile('spam', 0, 0, None, 3, 0x0200_0000, None)
    >>> print(win32file.GetFinalPathNameByHandle(h, 0))
    \\?\C:\Temp\test\test\spam

    >>> os.rmdir('spam')
    >>> print(win32file.GetFinalPathNameByHandle(h, 0))
    \\?\C:\$Extend\$Deleted\001000000000949A5E2FE5BB

Of course, none of the above is documented for RemoveDirectory().