For everyone with the same problem:
I have written a PowerShell script that will fix this bug after you installed PowerShell 7 Core (since PowerShell 7 Core is still shipped with this bug in it).
You can get the script here:
https://github.com/echalone/TUN/blob/master/PowerShell/Scripts/Tools/Local/Tools.Local.RepairPS7CorePowerShellGet.ps1
Be sure to execute this script with elevated/administrative privileges (it will try to restart itself with elevated privileges otherwise).

Whenever you installed OR updated PowerShell 7 Core on a machine, execute this script so my PowerShellGet Module Version 2 bugfix is applied. The script should find the installation directory on its own, but if not, you can provide the installatin directory for PowerShell 7 Core via the "PowerShellCorePath" parameter. The script will ask you for your confirmation if it should apply the fix, if you want to skip this confirmation add the switch -NoConfirm to your call of the script.
That's it, the script will search for the bug in your installed PowerShellGet module version and replace the line with the fixed line via a regular expression. Should the module already be fixed or of another version without this bug in it, then the fix will not be applied and you will be told so by the script. So it should be relatively save to run this script, even if you're not sure of your PowerShellGet module version. If it's one that needs to be fixed, it will fix it, if not, it won't, easy as that.

Since the new PowerShellGet module is still not ready and doesn't look like it will be anytime soon (it's more than a year now) I really think this bugfix should be added to this module even though its not under development any more. Your own Powershell Core Product still gets delivered with this faulty module and I'm sure it breaks the usage for many people,, maybe without them even knowing.