> My opinion is that no extra flags are necessary.  The default of 
> deleting on close is fine, unless a context manager is active -- in 
> which case delete on CM exit.

There is a use case of needing to let another thread or process open the temporary file while in a given context, but ensure that the file is deleted when the context exits. The O_TEMPORARY flag is not generally compatible with this use case, since very few programs in Windows share delete access. Python's open() doesn't, not without an opener. So this case needs to omit the O_TEMPORARY flag and rely on the context manager to delete the file.

If there's no need to reopen the file in another thread or process, then using O_TEMPORARY is preferred. In this case, the file will deleted even if the current process crashes or gets terminated (e.g. by a job object).

NamedTemporaryFile() in Windows could switch to relying on the context manager to delete the file. But also add an implementation of TemporaryFile() in Windows that uses O_TEMPORARY. Surely if a script has no need to reopen a temporary file, then it shouldn't care what the file's name is. 

For example:

    def TemporaryFile(mode='w+b', buffering=-1, encoding=None,
                      newline=None, suffix=None, prefix=None,
                      dir=None, *, errors=None):
        if "b" not in mode:
            encoding = _io.text_encoding(encoding)

        prefix, suffix, dir, output_type = _sanitize_params(prefix, suffix, dir)
        flags = _bin_openflags | _os.O_TEMPORARY

        (fd, name) = _mkstemp_inner(dir, prefix, suffix, flags, output_type)
        try:
            _os.unlink(name)
            return _io.open(fd, mode, buffering=buffering,
                            newline=newline, encoding=encoding, errors=errors)
        except:
            _os.close(fd)
            raise

Prior to Windows 10 (tested back to Python 3.2 in Windows 2000), the unlink(name) call will leave the file linked in `dir`, but trying to access it with a new open will fail with an access-denied error. A file that's in a deleted state is only accessible by existing opens. The downside is that the temporary file can't be moved to another directory except by an existing open (e.g. via SetFileInformationByHandle: FileRenameInfo). Another process that wants to delete `dir` won't be able to move the file out of the way. It shouldn't be an issue, however, if the file is created in the user's temp directory.

In Windows 10, NTFS implements a POSIX delete that also moves the file into a reserved system directory, so it doesn't remain linked in `dir` and thus doesn't prevent deleting `dir`.