Dude that's weak sauce.
- Some apps need to do extra processing
And then they close as expected.
- Many apps ask for user input (e.g. asking if you want to save)
That's pretty much expected behavior. And Windows Store apps can do the same but this should rarely happens since Windows Store apps should be persisting data all the time anyway (at least I thought that was the design pattern Microsoft suggested anyway).
- Some apps ignore standard app close behavior *cough Excel* but instead close just the top MDI child
Yep, that's bad form but for those apps it's expected. No reason to throw the baby out with the bathwater.
- Several apps don't actually quit but rather minimize to the system tray
Again that's the expected behavior for those apps. The vast majority of desktop apps don't do that. Those that do are typically helpers or service front-ends that typically have configuration options to disable that behavior.
Trying to tie Windows Store apps to the behavior of these corner cases simply ignores the behavior the vast majority of desktop apps and expectations of users that they appear in the taskbar. I stress "appear" because there's no reason that Windows can't suspend or terminate them and still leave them on the taskbar, in the desktop task switcher, etc. When a user clicks on the instance Windows simply relaunches the app. If it's a well behaved Windows Store app it will resume where it left off. If not it'll start the app over; users then can * to the app developers if they don't like that poor behavior.
For any of those cases, if you want to kill an app immediately, you need to use the Task Manager. And if an app isn't responding, you need to use the Task Manager. There are a host of reasons that the only way I can kill an app immediately is to do so via Task Manager.
This is true of both desktop and Windows Store apps. Why use it as an excuse to exempt Windows Store apps from supporting standard Windows close mechanisms. Windows Store apps currently support the standard <ALT><F4> close mechanism. Why not give them the close button chrome and add them to the taskbar like most every other Windows app?
So why do we suddenly need a separate mechanism to force kill metro apps? From my perspective, this isn't making it work like the standard desktop... it's making it something completely different.
So why do we need any window chrome on Windows desktop apps either? There are keyboard commands you can use to manipulate the window and close it? Based on your premise if you have one mechanism to do something you don't need another.
The application should have control over how it should respond to a close request. Perhaps that's what is missing (but I haven't done much WinRT programming so I'll defer to people who know whether this capability exists currently).
I believe WinRT apps are warned when they're about to be suspended or terminated and given a limited amount of time to persist state (kind of like Android and I would surmise iOS). That's one of their strengths and could be leveraged to make the app look like it was never suspended nor terminated even when resuming from an instance on the taskbar in the design I mentioned above.
Task Manager should be the last resort, where you tell Windows that in this case the human looking at the screen knows better than the app. And it should be the ONLY mechanism to do this, shy of CLI commands.
Absolutely. And with that purpose of the Task Manager in mind it certainly shouldn't be used as the excuse as to why Windows store apps don't have a close button for mouse users. A user closing an app signals "I'm done with this" which is altogether different than an out-of-control app.