I was asking more about your "What means the GP will have to use his work account on his personal computer just to jump into another machine", which doesn't make any sense to me. Why would they have to use their work account on their personal machine to RDP? Just use the account you're wanting to log in as. So if you're on your personal machine and want to log in to your work machine, just log in to the RDP session with the account INSERTWORKDOMAINHERE\username and your user account, and you'll be able to RDP. This works the same with local accounts or cloud accounts or other domain accounts or whatever. You don't need to have the account locally on your computer to be able to log in as that account with an RDP session.
And then all your hypotheticals speak to issues which don't involve RDP, at all, which I think shows where this disconnect is. RDP is not about sharing a currently active desktop session between two or more users, so all the hypotheticals you shared aren't the use case for RDP. RDP will transfer that console session to the new RDP connection. So say Alice is signed in to her computer locally, and then wants to ask Bob for some help. She shares the hostname for her computer, and tells Bob their login (a terrible idea regardless of it being a local or Microsoft account). Bob fires up RDP, connects using Alice's account, and now Alice's machine gets disconnected from that desktop session and is sitting at the login screen while Bob now has Alice's desktop session.
This doesn't matter if its a Microsoft account or a local account, this is just how the RDP protocol works on Windows. If you're wanting to have a screen share with the built-in Windows tools, the tool for that was Remote Assistance or Quick Assistant. The usefulness of that tool doesn't change whether using local accounts, domain accounts, or Microsoft accounts. Or just use a different tool altogether, of which there are many.