Allow Set-PSSessionConfiguration to modify default PSRemoting endpoints from PS5 to PS7 or back

Summary of the new feature / enhancement

As an admin, I would like to be able to control the default PSRemoting endpoints (e.g. microsoft.powershell) to point at a different version/executable of Powershell. Not only during installation, but at any time, using a single command like Set-PSSessionConfiguration.

Proposed technical implementation details (optional)

I've been thinking about the conflicting opinions on this WinRM endpoints issue. A lot of discussion and disagreement seems to be on when/whether the installer should force the default microsoft.powershell to update from 5.1 to 7. I guess I don't understand why that would have to be managed by the installation process. Shouldn't that be something that is easily changed by the system admin?

So while I'm not intimately familiar with PSRemoting endpoints or C# programming (sysadmin here), it seems to me this debate could largely be avoided by modifying PSRemoting endpoints to include the concept of endpoint aliases in addition to the existing 'standard endpoints' (what I would call the versioned Powershell.# and Powershell.#.#.# endpoints). These aliases would be simple labeled pointers that reference existing standard endpoints.

This approach would allow one to have all the versionless microsoft.powershell or microsoft.powershell.workflow or whatever endpoints an administrator could want and they simply point to one of the standard endpoints.

Then an admin could use Set-PSSessionConfiguration to update an alias pointer from PS5 to PS7 (or even from something like a PS7.0.3 to PS7.2.5 if they had multiple-versions installed on that system). Perhaps like:

Set-PSSessionConfiguration -Name "Powershell.7" -Alias "microsoft.powershell" -Force -Confirm:$false or Set-PSSessionConfiguration -Name "Powershell.7.0.3" -Alias "microsoft.powershell" -Force -Confirm:$false

This would update the existing endpoint alias microsoft.powershell (-Force required since the alias already exists) to now point to the Powershell.7 (or the specific Powershell.7.0.3) standard endpoint.

There are a couple benefits in my mind. The first is for PS maintainers, it removes the need to be concerned with modifying the default endpoint at PS installation time and introducing a system breaking change. This would be backwards compatible as it would simply create new standard endpoints for any installed versions that are missing like Powershell.5 and Powershell.5.1, and would convert existing versionless endpoints (e.g. microsoft.powershell or microsoft.powershell.workflow) to endpoint aliases referencing whatever standard endpoint version it was configured for previously (e.g. Powershell.5). So the presentation of the endpoints would remain the same to external systems and not break existing usage.

In addition, this benefits system admins as it provides simple flexibility for them to control what each endpoint alias points to and when it gets changed. If an admin would rather install PS7, verify and test their scripts and whatnot first, and then easily flip the default alias from 5.1 to 7 (possibly even easily rolling back should something not work as expected), they could do so in a single command - and one that already exists to configure endpoints.

The biggest challenge I see with this approach is that once someone installs PS7 and it updates the endpoints as described above, I'm not sure the scope of code changes that would be needed at the PS5 level so that if someone running PS5 attempted to modify the endpoints it would not error horribly. I suppose one approach could be backporting the same alias functionality - though that may significantly expand scope of work. I'm not sure. Or it could be something as simple as recognizing that if aliases exist, then it informs the user that these are PS7 endpoints and so PS7 is required to modify the endpoints.