My point isn't so much to reinvent Git's model (aka tree of blobs/commit/commit-graph), but rather to make it a part of a programmable interactive environment, and then just do the right thing from the user perspective.
That would include:
(1) Develop a UI for navigating the model,
(2) Develop a set of commands that act on the objects of that model.
I do want to append to the Git model by introducing the staging step for the whole tree (this, unlike with commits, won't have to have a history). I also think it could be possible to make it more flexible. So, you could say that there are blobs. But instead of blobs you could have some other kind of object too: for example the kind that would lazily compute itself from the definition of some other similar object. Or the kind of of object that would have knowledge about its contents, have an efficient way of storing it, maybe. So, I don't really want blobs (binary large objects), but rather a general kind of objects. Such objects would obviously need to conform to some API spec. Such objects could be written by the user (although, then he would have to supply the definitions to the others who want to use this). A tree could hold different kinds of such objects.
There's definititely some design that will have to go into commands. The commands would have to be taught to be context-sensitive (e.g. to selections or to the current state of the graph or commit).
A session-time undo graph for the repo-staging tree could be built as well. Easy implementation: copy the whole damn thing to memory on every change (only works for small repos, but that's a start). Harder implementation: define the inverses for the commands and build an undo graph.
I will admit: I am by no means an expert on version control systems. So, thanks for expressing the fact I didn't write about this, there's definitely some challenge to this, and I don't have any sort of final design in my head quite yet.