Just close. I want to issue a command and I want it carried out immediately.
If the software can't do that gracefully, then it's bad software.
Also, there is no reason for the operating system UI to ever be stuck. If the program fails to redraw, show it blank, but don't prevent me from moving/sizing it. Even if the CPU is at 100%, I want my commands to get 1st priority. Too many times I had to spam Ctrl+alt+del just waiting for something to respond.
Used to be: You throw a physical switch on the computer, it interrupts the power circuit from the power supply, and the computer went off instantly.
Today: You have to do it in some software menu, but invoking this, you're not even powering it off. You're requesting your computer to "pretty please, with sugar on top, turn off my computer when you're not too busy." Then the OS goes and does god knows what, maybe it decides to flush some caches, maybe it decides to do an entire operating system update, who knows--you're not the driver, you're just along for the ride.
Even the physical power button on the computer doesn't break a circuit anymore. It... you guessed it... sends a software signal begging the almighty operating system to please shut down.
And when you point this stuff out, all the excuses start coming out: "Bbbbut the OS has to flush its caches! Bbbbut the filesystem needs to write things to disk that are in-flight! Bbbbut applications need to gracefully shut down and free their memory (which is about to have the power cut). Bbbbbut there may be a critical background task still running that needs to...." I don't fucking care! I didn't command my computer to do any of these things.
It's gotten to the point where if you want to shut your computer down instantly, you need to pull the power plug or remove the battery. I expect we software engineers will fix that one some time soon, too.
This captures my sentiment towards current trends in technology so aptly. I went to turn off a Windows machine the other day and the only options required allowing an update to be performed. There was no way to shut down or restart without allowing an upgrade. Fortunately I could bypass via the command line but this level of mediation is unwanted and abhorrent.
Just don't complain the next time you start it up that disk files you were writing to when the power failed are corrupted.
Holier-than-thou victim blaming may be a good excuse in FOSS land but we pay Microsoft money for Windows and Apple money for macOS X, and both companies are capable of building stuff which can recover from interruption. Even JETDB is surprisingly resilient when you force-reboot an Exchange server these days, so is SQL Server, so is Active Directory, so is NTFS.
That should never, ever, ever happen if your OS and filesystem are even remotely quality software.
Also, you're assuming that there is a thread that saves state to disk. There may be (and if the state save is a significant operation, there probably should be). But that's far from always the case.
If the GGP wants "Cmd-q" (for example) to cause a program to immediately stop using system resources, then all the "responsive" in the world will not satisfy that goal.
I agree that if GGP wants "Cmd-q" to cause a program to immediately vanish from the screen, the responsive design is the answer.
However, adding a thread to a program that takes 1 second to save it's state to disk in order to allow Cmd-q to cause the window to vanish immediately feels like overkill to me. You now need a bunch of thread mutual exclusion primitives that were (potentially) not necessary before. Not doing this is not "not bothering". It's facing the tradeoffs from adding a thread and deciding it is not worth it (a decision the user may not agree with).
I'm not into the proposed "saving threads", I'm afraid they will get stuck for whatever reason without you noticing (as the window/taskbar icon already disappeared).
Nowadays the software should just auto-save it for you. But not all software is that well written, and the OS can't tell it apart.
Thankfully for SuperF4, it will force exit the game or any app that I have it focused on. I had one game that outright shamed me for doing that and I never went back to that game again. Sorry, I don't have time for games that chose to lock out the exit and three-finger salute command. SuperF4 is the boss now and there nothing that those games can do.
On the other hand, macOS is wonderful because, if you don't want ⌘Q to do that, then you can re-bind the Quit command, and programs respect that. (I don't remember if programs have to opt-in to respecting it, or if the OS enforces it.) I know that various flavours of Linux can do this easily too, but I think that Windows doesn't have a native such feature.
The fact that remapping commands requires an exact, case sensitive match of the localized menu item label you have to type in by hand (and cannot copy to your clipboard) though...
I force quit apps all the time, sometimes even because I want them to restore their exact state. In a lot of apps, the macOS state restoration works great, possibly better than actually quitting them.
What I want is that the software itself doesn't even get a chance to interfere with demands like ⌘Q. There's no reason Chrome should get to decide that it doesn't close until I hold ⌘Q; that way lies all sorts of dark patterns. (Adobe's attempt to seize control of basic OS functions is my bugbear here.)
I don't mind the OS having a system-wide setting whereby I can decide how much I want it to protect me from the consequences of my actions, but that should be a decision between me and the OS, enforced by the OS, not something I have to negotiate individually with every app.
(Same with the menu bar. I choose what goes in the menu bar, and macOS should enforce that choice, not tell me that the software has decided what goes there and I have to lump it.)