I think the issue (which seems to exist in pretty much every VCS out there) is that there is a single flat timeline - even with branches (assuming they aren't treated as just separate parts of the tree) you get a single timeline per branch at best.

Wouldn't it be better to be able to "nest" or "group" commits so that, e.g. all the "intermediate" commits go under the final commit which is what is displayed by default and "traveled" through via tools like log, blame, etc?

Right now the best (though really not solving the issue) is to have a branch per task for VCSs where branching is trivial but this doesn't really solve it since you still get all the commits in your history anyway (i think some clients can display only the merge, but this is up to the tool, not an inherent feature).

There was the other day a submission about a project on github where people noticed that the git history looked as if the author was making a new commit automatically every time he saved a source file and most comments were about how bad that it was. And i was thinking "Why? The issue here is that you can see those commits, not that they exist".

You could easily have something like

    * Feature #1 submission
    * Feature #2 submission
      * Quick prototype hack
        * Save at 12/13/14 09:30
        * Save at 12/13/14 09:31
        * Save at 12/13/14 09:41
          ...
      * Attempt #1
        * Save at blahblah
        ...
      * Attempt #2
        * Save at blahblah
        ...
      * Final Fix
        * Save at blahblah
        ...
    * Bug fix for #8923
      * Attempt #1
      * Review update
      * Etc

and by default in the timeline/log you'd only see the top three commits until you drilled down, even to automated ones from file saves. Similarly when you looked at "blame" (or whatever) you'd see these commits. And of course all these tools should have a "max depth" (default 1) to allow you go into more detail. And yeah, you'd also need some functionality to specify and edit (preferably with its own history - Fossil already does that for other stuff like wiki) the parent/child relationships, perhaps with some current state (ie. under which commit all new commits will be placed).

With something like that in place i do not see any reason to not keep as much as possible around.