> In contrast, in the case of CreateProcessW, both Path('./exec') and 
> Path('exec') are the *correct* paths to the executable. The ./ is not 
> necessary in that case to display the path correctly, but just to 
> interact correctly with CreateProcessW's interface.

It's semantic information, just for different reasons than the "./c:a" case. In this case, it's about what a path means in a search context. I think specifying a filesystem path for a search disposition is as valid a use case as is specifying a path for an open or create disposition. 

In Windows, the qualified path r".\exec" is resolved relative to just the working directory. Classically, for an unqualified name such as "exec", the working directory is checked after the application directory. Starting with Windows Vista, CreateProcessW and the CMD shell won't check the working directory at all for unqualified "exec" if NoDefaultCurrentDirectoryInExePath is set in the environment, not unless a "." entry is explicitly added to PATH.

The behavior of CreateProcessW also differs for r".\spam\exec" vs r"spam\exec". Without explicitly including the leading ".", the system searches every directory in the executable search path (i.e. the application directory, working directory, system directories, and PATH). This differs from Unix, in which any path with a slash in it is always resolved relative to the working directory. Getting this behavior in Windows requires using the qualified path r".\spam\exec".

We may want either behavior. I think if a path is specified explicitly with a leading "." component, or joined from one, the "." component should be preserved, just as we already preserve a leading ".." component. 

This is a separate issue, as I suggested in the PR comment. It was just supposed to be a related issue that you might be interested in. I didn't intend to conflate it with this issue.