Sometimes I might stage only part of the changes in a single file. Sometimes I want to stage a file or two, see what’s remaining, and decide what else should be in this particular commit. I can and do diff only staged changes, then diff only unstaged changes, to decide how to proceed. Sometimes I unstage certain changes if I decide that no, they in fact should not be in this next commit.
Basically, it’s a scratchpad that’s gives me space to think and plan.
Agreed. After getting used to that model for building up a particular commit, I wouldn't want to go back to the mercurial way.
I used to use mercurial back in the day, before git took over the planet. Switching back to it would be slightly analogous to switching keyboard layouts at this point. Sure, qwerty is arbitrary and sort of stupid, but I've spent so much time using it that I've gotten used to where everything is.
You have a git workflow that works for you, which is great. But you can't really compare unless you use the appropriate hg features to accomplish the same things. You're talking about a bunch of use cases, so I'd have to throw a bunch of commands at you. But basically, I do all of that, every day, with hg commands and I really dislike the added mental overhead of the staging area every time I use git. (Not that I'd try to use git without it; common usage is built around it.)
In short, for similar scenarios I'd do `hg commit -i` to select a couple pieces I was sure I wanted in the commit, then `hg diff` to see remaining pieces or `hg diff -c .` to see my commit so far, then `hg amend -i` to select additional fragments or files. To undo some of that, I'd use `hg uncommit`. Same effect, fewer concepts -- your stage/index/cache is just materialized as a plain everyday commit that you can decide is done at any time.
I'm not going to argue that suddenly every vcs task becomes trivial with hg. Far from it. And these discussions often get bogged down when people argue from the standpoint "I only need X so everything else is unneeded complexity" or "you need all of this stuff because you might need to collaborate with multiple remote people editing the same files who need to back out some of your changes while they're working and have everything magically put back together at the end, oh and we need full control over what the final history looks like too." These VCS systems have to deal with a wide range of complexity, and reductive takes like "you really only need these 3 commands; why is it so hard??" don't illuminate anything. (Note that I'm not addressing this at your comment, which was not at all doing that.)
I don't often need this, but in Hg I simply use commits for that and use histedit to clean up later. The staging area basically is just a commit, just one that's not part of your history yet.
Basically, it’s a scratchpad that’s gives me space to think and plan.