This is essentially a duplicate of #19411 (comment)

I do not agree that it is a duplicate. Perhaps the background reason is the same .Net issue but it are completely different powershell issues.
The same .Net problem were mentioned as the background reason for the -Wait problem on the start-process, but that was solved, so why can these issues not be solved used the same (interrnal) technique?

It is, the process object you get back from Start-Process is very limited in what you can do as your user does not have permissions to work with that token.

The same .Net problem were mentioned as the background reason for the -Wait problem on the start-process, but that was solved, so why can these issues not be solved used the same (interrnal) technique?

Using Start-Process -Credential ... -Wait was solved because internally it still had access to the process token given to the user when it created the process. This token had full access to do whatever it wanted, like wait until it was done ("synchronization rights"). Unfortunately that full process token is discarded as dotnet has no way to say hey give me a System.Diagnostics.Process object from that process handle. It is forced to use [System.Diagnostics.Process]::GetProcessById($newProcId) to get a new process object but now it's subject to the same access checks that user normally would have when inspecting other processes.

The ultimately fix is to stop doing the work manually in Start-Process to spawn the new process and just use the dotnet API directly as now that Process object has the process token with full access on it. This was not possible before as dotnet didn't expose all the options that pwsh has but with the merging off dotnet/runtime#82662 it should now be possible to do so.

Ok I understand that during start-process the solution could be different (because of the internal available token), But why does $p.WaitForExit be different then Wait-Process while they both only wait for the process itself (while start-process -Wait should/will wait for the full process-tree (also started child processes!)

The process object you get back from Start-Process -PassThru doesn't have enough rights on the process itself. to do things like waiting for it to exit or checking the exit code. This is because your user account doesn't have permissions over the new process that is running as another user. It's like doing:

Start-Process pwsh.exe -Credential $cred
$proc = Get-Process -Name pwsh
$proc.WaitForExit()

Windows does give the creator of the new process a handle to that process with full access to do whatever they want but the way PowerShell starts it and how dotnet works it is unable to embed that token in the Process object returned by Start-Process. The only way around this is to have dotnet create the process as another user as in that scenario the process object contains that full access handle.