> if the operation succeeds, no error/message is displayed

Some errors pass silently and may be confusing later on. For example, CreateDirectoryW calls NtCreateFile with the disposition FILE_CREATE and the option FILE_DIRECTORY_FILE (i.e. the call *must* create a new directory), but some non-filesystem devices ignore this and let the request succeed. For example:

    >>> os.mkdir('C:/Temp/nul')
    >>> os.mkdir('C:/Temp/conin$')

Both calls 'succeed' but don't actually create a directory:

    >>> os.path.exists(r'\\?\C:\Temp\nul')
    False
    >>> os.path.exists(r'\\?\C:\Temp\conin$')
    False

> either we need to search the string for the special names or find 
> an API that will clarify it

GetFullPathNameW is a library function that shares the implementation that's used to normalize paths in a create or open context. 

If the path does not start with \\?\, then we resolve it via GetFullPathNameW. If it becomes a device path, or if the final component changes (e.g. a trailing dot or space is removed), then we can parenthetically include the resolved path. For example:

os.stat('spam.'):

    FileNotFoundError: [WinError 2] The system cannot find the file specified: 'spam.' [resolved path: 'C:\\Temp\\spam']

os.startfile('con'):

    OSError: [WinError 1200] The specified device name is invalid: 'con' [resolved path: '\\\\.\\con']

os.open('C:/Temp/lpt9', 0):

    FileNotFoundError: [Errno 2] No such file or directory: 'C:/Temp/lpt9' [resolved path: '\\\\.\\lpt9']

For os.open() and open(), we should switch to using PyErr_SetExcFromWindowsErrWithFilenameObject instead of PyErr_SetFromErrnoWithFilenameObject. _doserrno is valid in this context, so we should be using it anyway to retain the more specific winerror value. Then we only have to special case reserved names in the Windows-only function PyErr_SetExcFromWindowsErrWithFilenameObjects.