They work just fine, as the drive-specific CWD is stored in the environment as a normally-hidden =<drive-letter>: environment variable which has all the same WTF-16 and case-insensitive properties as drive letters:

    C:\> cd /D λ:\

    λ:\> cd bar

    λ:\bar> cd /D C:\

    C:\> echo %=Λ:%
    λ:\bar

    C:\> cd /D Λ:

    λ:\bar>

Hm, what about using `%` itself?

That would only interact with the shell, as `%` is not actually part of the environment variable name, it's just a way to tell the shell you want it to get the value of an environment variable. The environment block itself is a NULL terminated list of NULL terminated WTF-16 strings of the format <key>=<value>, so `=` would be the more interesting thing to try.

And indeed, it looks like using `=` as a drive letter breaks things in an interesting way:

    =:\> cd bar
    Not enough memory resources are available to process this command.

    =:\bar>

`cd` exits with error code 1, but the directory change still goes through.

With a program that dumps the NULL terminated <key>=<value> lines of the environment block, it looks like it does still modify the environment, but in an unexpected way:

Before `cd /D =:\`, I had a line that looked like this (i.e. the per-drive CWD for C:\ was C:\foo):

    =C:=C:\foo

After `cd /D =:\`, that was unexpectedly modified to:

    =C:==:\

Funnily enough, that line means that the "working directory" of the C drive is `=:\`, and that actually is acted upon:

    =:\foo> cd /D C:

    =:\>

---

You might also be interested to know that '= in the name of an environment variable' is a more general edge case that is handled inconsistently on more than just Windows: https://github.com/ziglang/zig/issues/23331