Windows path with no slash after drive letter and colon - what does it point to?

This is standard DOS/Windows behavior and has always been like this. Open a command line and see:

C:\Users\Tim>d:              # change current drive to d:
D:\>c:                       # change back to c: - back in the same directory
C:\Users\Tim>cd d:\users     # change current directory ON D:
C:\Users\Tim>cd \            # still same directory - backslash leads to top dir
C:\>d:                       # change current drive to d:
D:\Users>                    # notice that we're now in the directory D:\Users

The drive letter always references the current directory of that drive; the (leading) backslash gets you to the top directory.

Here is the documentation/explanation, courtesy of Harry Johnston's comment.

MSDN --> Windows desktop applications --> Develop --> Desktop technologies --> Data Access and Storage --> Local File Systems --> File Management --> About File Management --> Creating, Deleting, and Maintaining Files --> Naming Files, Paths, and Namespaces --> Fully Qualified vs. Relative Paths

For Windows API functions that manipulate files, file names can often be relative to the current directory, while some APIs require a fully qualified path. A file name is relative to the current directory if it does not begin with one of the following:

• A UNC name of any format, which always start with two backslash characters ("\"). For more information, see the next section.
• A disk designator with a backslash, for example "C:\" or "d:\".
• A single backslash, for example, "\directory" or "\file.txt". This is also referred to as an absolute path.

If a file name begins with only a disk designator but not the backslash after the colon, it is interpreted as a relative path to the current directory on the drive with the specified letter. Note that the current directory may or may not be the root directory depending on what it was set to during the most recent "change directory" operation on that disk. Examples of this format are as follows:

• "C:tmp.txt" refers to a file named "tmp.txt" in the current directory on drive C.
• "C:tempdir\tmp.txt" refers to a file in a subdirectory to the current directory on drive C.

[...]

It uses the current working directory on that drive. Each process "remembers" a current working directory per drive:

 C:\> cd somepath\subdir
 C:\somepath\subdir>  d:
 D:\> dir c:subsubdir       <--  refers to C:\somepath\subdir\subsubdir

When you specify a path with a drive letter but no initial backslash, it is typically interpreted as a relative path to the current directory on the specified drive. In particular, this is how ordinary Win32 API file functions will interpret it; therefore, most software which passes unmodified file paths to Win32 file functions will also behave this way.

On my machine, this works as expected in PowerShell, except for one complication:

C:\Users\social>powershell
Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.

PS C:\Users\social> [System.IO.Path]::GetFullPath("c:foo.txt")
C:\Users\social\foo.txt
PS C:\Users\social> cd \
PS C:\> [System.IO.Path]::GetFullPath("c:foo.txt")
C:\Users\social\foo.txt
PS C:\>

What we see here is that when we change the current directory in PowerShell, it doesn't actually change the current directory. That is, PowerShell has its own idea of what the current directory is, but hasn't bothered to tell Windows about the change. You can confirm this with Process Explorer (which can be downloaded from Microsoft's web site); in the above case, even after using cd, the actual current directory for the PowerShell process was still C:\Users\social.

You also mention Explorer. As near as I can figure, Explorer does its own validation of the path that it is given, which for whatever reason does not permit drive-relative paths. If the path is not considered valid, or does not point to an actual file/folder, the default action is to open the user's Documents folder.