First, let me provide some context:

• Libraries are collections of folders, so it doesn't make sense to offer an "Open here" shortcut-menu command on them, as there'd be no single folder to navigate to (in File Explorer, a virtual view spanning multiple folders can be presented, but there's no console (terminal) equivalent).

• Libraries were introduced in Windows 7, but it seems that they've been de-emphasized starting with Windows 10: they're hidden by default now.

• In Windows 11, in general, File Explorer shortcut (context) menus present a simplified view; in order to see all available shortcut commands, you either need to hold down Shift while right-clicking, or select the Show more options in the menu that shows after a regular right click.

Note: The Windows 11 (W11) statements below are based on the 22H2 version I'm running.

The fact that the PowerShell MSI installer defines a HKEY_CLASSES_ROOT\LibraryFolder\background\shell entry - note the background part - means that the commands defined this way are not meant to be available at the level of individual libraries; as argued above, this wouldn't make sense.

Instead, this entry relates to right-clicking on the background of the virtual Libraries folder view.

The limited utility this hypothetically provides - opening a PowerShell terminal in $env:APPDATA\Microsoft\Windows\Libraries - is thwarted in practice: on W11 (22H2), the operation is a quiet no-op, for reasons unknown to me - this does sound like a Windows bug.

PowerShell uses a central definition in HKEY_CLASSES_ROOT\Directory\ContextMenus\shell for all of the following: drives, regular folders (and their backgrounds), the desktop background, and the library background, which is based on passing the target directory via %V.

Things are different in the tree view (left sidebar):

• First, in Windows 10, if memory serves, but definitely in Windows 11, you must explicitly enable showing libraries in the tree, by right-clicking on the background and selecting Show libraries.

• Once you've done so, it seem that it is again Windows bugs that surface:

  • The Libraries node itself, is arguably a regular folder - namely $env:APPDATA\Microsoft\Windows\Libraries - but neither PowerShell's nor other application's commands seem to work on it (quiet no-op in W11; per your screenshot, an error in W10).

• By design, the PowerShell commands should not be offered on the individual library nodes (just like they aren't offered on the icons representing the individual libraries in the folder view):

  • In W10, per your screenshots, they commendably aren't.
  • In W11, unfortunately, they are, and - again - they do not work.
  • (By contrast, at least in W11, they are and should be offered on the individual folders that make up a given library, on which the PowerShell commands do work.)

A mitigation of the problem is to make the MSI installer not write an HKEY_CLASSES_ROOT\LibraryFolder\background\shell entry:

• This wouldn't be much of an improvement on W10, except to not present the - presumably non-functional - PowerShell commands when right-clicking the background of the folder view.

• On W11, additionally, it would remove the non-functional - and conceptually pointless - PowerShell commands from the individual library nodes in the tree view.

The bug with respecting to right-clicking the Libraries node itself in the tree view would persist, however.

As an aside:

• The MSI installer also offers an Add 'Run with PowerShell 7' context menu for PowerShell option, to allow running individual .ps1 files directly from File Explorer.

  • As a (nested) aside: If this option did work (see next point), it would be hampered by invoking the script without the -NoExit CLI switch, meaning that scripts will by default automatically exit the session and thereby close their console window - the same applies to the analogous command that Windows PowerShell defines.

• However, on my W11 (22H2) machine, this command never shows - for reasons unknown to me.

  • As a(nother) (nested) aside: The intended - but ineffective - command is problematic in itself:

    • C:\Program Files\PowerShell\7\pwsh.exe -Command "$host.UI.RawUI.WindowTitle = 'PowerShell 7 (x64)'; & '%1'"
    • First, the lack of quoting around the pwsh.exe path - despite its containing spaces - is conceptually problematic, though - surprisingly - in itself that is not a problem.
    • '...' quoting around %1 isn't robust, given that ' is a legal file-name character.
    • Thus, the command line should be:
      • "C:\Program Files\PowerShell\7\pwsh.exe" -Command "$host.UI.RawUI.WindowTitle = 'PowerShell 7 (x64)'; & \"%1\""