We need a place to install modules that target both legacy and modern PS, that does not require elevation

Summary of the new feature / enhancement

The problem

PowerShellGet/PSResourceGet works in both legacy Windows PowerShell and modern PowerShell. Each version of PS has its own, version-specific directories where they install modules. However, some (many?) modules target both legacy and modern PS. This means that users generally have to Install-Module from each version of PS that they want to use the module from.

This is a problem.

1. As a module developer, I don’t want to deal with people complaining “I installed it last week, and it was working fine, but today PS says it can’t find the module!” (Because now they are running in a different version of PS.)
2. I don’t want to have to write up detailed instructions about how there are two versions of PowerShell, and you should probably install the module for both versions.
3. Certain modules may be more sensitive to unfortunate situations that could arise if a user ended up with two different versions of the module for the different versions of PS. (I have such a module; I can handle a vX <-> vX+1 situation, but would like to minimize the possibility of vX <-> vX+ALot.)

My understanding is that there is one way to get a module installed into a single location that can be "seen" by both versions of PS: if you install machine-wide from legacy PS, it goes into a ProgramFiles location that modern PS is also willing to load modules from.

But this still complicates things for me: I have to rely on user education ("please do it like this"), and people who do not read the instructions carefully will "get it wrong".

The request

We need a [user-specific] place in $env:PSModulePath where both versions of PS will look for modules, and modules that support both versions should get installed there. There should be a way for users to manually install to this location (for modules that aren't or can't be specially marked (such as due to https://github.com/PowerShell/PowerShell/issues/10931)).

Proposed technical implementation details (optional)

The hardest part might be picking the name for a directory for modules that support multiple versions of PS.

Start by reviewing how $env:PSModulePath differs between legacy and modern PowerShell, then trace the Install-Module flow and the manual installation path. Done means defining a user-specific shared location visible to both versions and providing a way to install modules there without elevation.