The underlying design issues are:
a) there's no Xserver concept of a lock screen which would be hard to fix, I suspect. How would you signal X to lock/unlock; what would it do if the lock client wasn't connected, etc.
b) there's no atomic way to transfer mouse/keyboard grab to another window, which means you can't have a reliable, crash reduced screen locker that supervises a beautiful password checking program; it has to be the same program. This could probably be fixed with an X extension; yes, an extension is a lot of work, and yes, you'd have to deal with fragmentation, but you could keep the untoolkited password dialog in case the extension isn't present, nobody would see it unless they did something odd, so it's fine.
Another issue is that I think I've seen some linux systems don't launch the screen locker until resume, instead of locking before suspend; that's not ideal, because the screen locker will take time to launch and lock the screen (more so if it's got a fancy initialization routine and is a large binary/many libraries to load).
An option could be running a dedicated screen lock Xserver on a different VT, and (securely) switching to that one somehow. But that would probably involve changes to multiple layers at the same time, which is hard to pull off in Linux. People would complain about the bloat of running a second Xserver, regardless of the actual bloat or imcreased utility.