> Honestly, the only real problem I've seen is in applications that use
> a reimplementation of spawn() rather than the UCRT's version (which
> handles the reparse point jsut fine).

I looked into this spawn problem. It's due to Cygwin's spawnve, which calls NtOpenFile to open the file, and then memory-maps it and reads the image header [1]. For an app-exec link, this fails with STATUS_IO_REPARSE_TAG_NOT_HANDLED, which is translated to Windows ERROR_CANT_ACCESS_FILE (1920). In turn, Cygwin translates this error to its to default errno value, EACCES. (The Windows CRT uses EINVAL as the default.)

[1] https://github.com/cygwin/cygwin/blob/aa55d22cb55d67d7f77ee9d58f9016c42c3ee495/winsup/cygwin/spawn.cc#L1035

> Maybe it can just return bytes and let the caller do the parsing?

It could parse out as much as possible and return a struct sequence:

    ReparseTag (int)
    ReparseGuid (string, or None for Microsoft tags)
    SymlinkFlags (int, SYMLINK_FLAG_RELATIVE) 
    PrintName (string or None)
    SubstituteName (string or None)
    DataBuffer (bytes)

Only the ReparseTag and DataBuffer fields would always be present. ReparseGuid would be present for non-Microsoft tags (i.e. bit 31 is unset). The result could maybe have one or more fields for the app-exec-link type.

> This sounds like a good option to me, too. So that would suggest that 
> Modules/posixmodule.c in win32_xstat_impl would verify both 
> FILE_ATTRIBUTE_REPARSE_POINT and IO_REPARSE_TAG_SYMLINK? And if the 
> tag is different it'll return information about the reparse point 
> rather than the target?

Maybe have two non-overlapping options, follow_symlinks and follow_nonlinks. The latter might be more sensible as a single option for lstat(), since it never follows symlinks. Then if either follow_symlinks or follow_nonlinks is false, stat has to open the reparse point and get the tag to determine whether it should reopen with reparsing enabled.

The straight-forward way to get the tag is GetFileInformationByHandleEx: FileAttributeTagInfo. This should succeed if the file system supports reparse points. But still check for FILE_ATTRIBUTE_REPARSE_POINT in the attributes before trusting the tag value. If the call fails, assume it's not a reparse point and proceed to GetFileInformationByHandleW.

Another tag to look for is IO_REPARSE_TAG_AF_UNIX (0x8000_0023). It's relatively new, so I haven't used it yet. I suppose it should be mapped S_IFSOCK in the stat result.