"DOS Devices" to directory (aka permanent SUBST) not honored after Windows 21H1 update

Previously, a device mapping had been established using HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices to add an alias from D:\ to C:\Build. This approach discussed in the wikipedia SUBST article and similar.

After updating to Windows 21H1 this registry setting was removed¹, and even after re-adding the setting, the "D:" device is not being enumerate in Explorer, powershell, or bash-git (mingw).

After the installation the "DOS Devices" registry section has been updated¹ to add a the registry key shown below. However, this does not seem to take effect. How can I restore this 'permanent subst' functionality to a directory target?

Name   ValueD:     \\??\C:\Build

• ¹https://www.satsignal.eu/software/Win-10-notes.html notes that the "DOS Devices" are deleted and have to be manually added back (in Windows 10 build 2004). It makes no mention of this functionality being removed. I have re-added the DOS Devices entry back and the mapped drive is still not appearing.

• Using WinObj (from Winternals) shows the correct Name and Symbolic Link Target in GLOBAL?? for "D:".

• The "C:\Build" directory exists with standard permissions (eg. SYSTEM full control, Authenticated Users all-but full control, Users with read access).

• This was an in-place update of Windows 10 to 21H1. The previous version was probably Windows 10 build 1909 and it was definitely not 20H2.

• Either net use or an equivalent is not an alternative solution in this case. The access must be an alias at the kernel/driver level to expose the underlying filesystem at full performance and features.

With the "DOS Devices" entry in Windows 21H1, the "D:" device is still somehow known to windows and cannot be used with the SUBST command even though it is not enumerated or otherwise accessible.

C:\Users\me>subst X: C:\BuildC:\Users\me>subst D: C:\BuildInvalid parameter - D:C:\Users\me>D:The system cannot find the drive specified.

Per a suggested answer, New-PSDrive has been attempted. However, this approach does not appear to be a suitable replacement for at least two reasons:

• Unlike SUBST, New-PSDrive -Name "D" -PSProvider "FileSystem" -Root "C:\Build" is not enumerated by different programs in the same session. For example, no new "D:" drive will show up in Windows Explorer.

• New-PSDrive .. -Persist only works on networked filesystems (even if local). This is unsuitable for general usage due to reduced performance and reduced filesystem features.