What I never fully understood is why the staging area isn't simply a commit that gets amended repeatedly as files are staged into it. Maybe just a tree pointer, since the rest of the commit data isn't available until commit, but you could fill in some placeholders. ("(staging)" for the message, current times for the timestamps, etc.)

(Note that index doubles for other functions like merging/conflict resolution, but I never thought that was a good thing, and could be separated out.)

I've wanted this for a long time, and also a frequently-amended working-tree-as-a-commit.

Why? I prefer a each branch to have its own staging area and working tree, which maps better to my mental model of "branch as an under-development feature".

Currently my workflow to achieve this involves a lot of stashing.

Do you know about git worktree? Because that sounds exactly what you want. Each worktree has its own index (staging area) and working tree.

What's the difference between a stash and a "working tree as a commit"?

The 'staging' area is implemented through the index. And the index is used for more things then just deciding what gets in the next commit. A lot of gits speed comes from caching Stat data of files so that it does not have to hash the complete working tree for each operation. That's not something you can just ignore.

Someone proposed splitting this up the other day, but even that would come at the cost of performance and an increase of complexity.

Wow, I just totally assumed the index was a tree object. It seems much less elegant that it isn't.

Maybe it isn't because it would necessitate creating a lot of blob objects as you staged and unstaged changes, which might not get garbage collected for some time. I can't see any other reason.