It's not an X11 design flaw. The very concept of locking the screen is flawed. A flaw that also haunts Wayland, BTW.
The concept of screen lockers is having a special layer, that can't be bypassed, which a locker creates. The whole security then hinges on the locker not crashing. X11 does have such a layer. Wayland compositors also implement it through such a layer. And for either the situation is, that if the locker crashes, that layer is destroyed by implication and the session exposed.
That's a flawed concept.
What you really want is detachable graphics session. On the text console one can effortlessly use screen or tmux and to "lock" the session simply detach and exit to the regular login getty.
You want exactly the same, but for X11. And there's no obstacle in printiple to implement this. It's just that the Xorg server can't detach. Almost all of the required code is there, fundamentally it'd be the same code that's executed during a VT switch.
In the meantime one can use Xpra with Xvfb to create detachable X11 sessions, which then however lack GPU acceleration.
The architecture you're describing would also be good for other reasons. For example, you could start a local session, lock it, and then remotely connect to the same session over VNC without local users at the workstation being able to see or interfere with what you are doing, just as on Windows.
Mac OS almost gets this right, except it annoyingly defaults to sharing the remote session with the local console unless someone is already logged in locally.
that's a really good point! your comment reminded me that that is what we used to do in the lab at university, a long time ago. switching to a different terminal, then locking that, was much more fool proof. perhaps not for security, but rather because X11 was so damned buggy and crashy, that you might need to have access to that terminal to get back into your workstation without forcing a reboot.
Perhaps outside of display servers altogether, implementing an authentication system that keeps track of what user currently owns what v.t., and allowing only that user, or root, to switch to that v.t..
Windows has a secure desktop that host lock screen. Crash that gives you a bsod or at worst a blank screen (your window did not host on it, whta did you expect?)
The concept of screen lockers is having a special layer, that can't be bypassed, which a locker creates. The whole security then hinges on the locker not crashing. X11 does have such a layer. Wayland compositors also implement it through such a layer. And for either the situation is, that if the locker crashes, that layer is destroyed by implication and the session exposed.
That's a flawed concept.
What you really want is detachable graphics session. On the text console one can effortlessly use screen or tmux and to "lock" the session simply detach and exit to the regular login getty.
You want exactly the same, but for X11. And there's no obstacle in printiple to implement this. It's just that the Xorg server can't detach. Almost all of the required code is there, fundamentally it'd be the same code that's executed during a VT switch.
In the meantime one can use Xpra with Xvfb to create detachable X11 sessions, which then however lack GPU acceleration.