Xrdp can't give you a console interactive session.
On Windows I can log into a local session on my console. Then lock the screen and walk away.
On another machine anywhere on the planet, I can then log back into that same local session, and do a bunch of work. Locally, the screen remains locked and secure.
Then I can eventually walk back to that machine, and log back onto the local console and continue exactly where I was.
There is no performance penalty for this - my local session runs exactly as it normally does. The remote session is very fast and efficient.
There is no way that I know of on Linux to replicate this: you have to commit to either a session being "virtual" and running through remote desktop (x2go is the best at this) or "local", in which case you get a less performant screen-scraping session but worse while you're using the session remotely the screen is unlocked and visible and usable by anyone with local physical access (i.e. in a shared office perhaps).
It's a problem which should be treated as a massive, ongoing embarrassment for desktop linux, and a substantial impediment to any notion of wider enterprise adoption: I've been in office's where the standard way everyone worked was remote desktop'ing to their office PC workstation via a VPN and seamlessly going from remote to local sessions was a crucial part of the experience.
Really we probably just need to solve the screen lock problem: but getting the experience (i.e. resize, resolution and app sessions) working properly is also important.
Interesting, my problem was exactly the opposite - I wanted a multi-seat access system with ability to work locally independently of other sessions which is somewhere between painful and impossible to set up on Windows. But I see your point, this is something I hadn't considered. Maybe attaching to the remote desktop system from localhost could work, although the slight decrease in performance would probably drive me nuts.
That's a licensing issue - Windows 10 is perfectly capable of doing this, but it's tied to having a Windows Server instance and remote desktop licenses and blah blah blah <proprietary things>. But if you have all that it does work! And it works the same way - multiple users can come back to the same console and resume their session or whatever.
RDP on Windows works really, really well - to the somewhat absurd outcome of course that because of that, it is easier to run Linux locally and Windows remotely when you can use Remmina to connect to the Windows machine so easily.
But the remote Linux experience really should be better.
VNC-like performance, so functional but not really what I consider usable in day-to-day work.
Also, IIRC, it didn't support seamless local vs remote sessions.
That is, if I started a session remotely, I couldn't resume it when I got back home. Or vice versa, if I started the RDP server on my logged-in session, I couldn't start a new session remotely in case the desktop rebooted (updates, power loss etc).
With Windows I just log in regardless.
Granted it's been a couple of years since I last took the rounds to evaluate the field, including Xrdp, so I'll give it another whirl soon.