Well; yes; the tool can't read your mind whether you'd like to batch a new change with an existing one, or make a separate commit.
Remember that git, initially, didn't hide the index in the add + commit workflow! You had to "git add" and then "git commit". So the fact there is only "git commit" to do everything is because they realized that the index visibility is an anti-pattern and suddenly wanted to hide it from view.
Since the index is already hidden from view (and largely from the user's model of the system) in the add + commit workflow, we are not going to optimize the command set by turning the index into some other representation. That's not what this is about.
The aim is consistency elsewhere.
For instance, if the index is an actual commit, then if we abandon it somehow, like with some "git reset", it will be recorded in the reflog.
Currently, the index is outside of the commit object model, so it gets destroyed.
It's possible for a git index to have content which doesn't match the working tree; in that case when the index is lost with a git reset, that content is gone.
If the index is a commit, it can have a commit message. It can be tagged, etc.
Remember that git, initially, didn't hide the index in the add + commit workflow! You had to "git add" and then "git commit". So the fact there is only "git commit" to do everything is because they realized that the index visibility is an anti-pattern and suddenly wanted to hide it from view.
Since the index is already hidden from view (and largely from the user's model of the system) in the add + commit workflow, we are not going to optimize the command set by turning the index into some other representation. That's not what this is about.
The aim is consistency elsewhere.
For instance, if the index is an actual commit, then if we abandon it somehow, like with some "git reset", it will be recorded in the reflog.
Currently, the index is outside of the commit object model, so it gets destroyed.
It's possible for a git index to have content which doesn't match the working tree; in that case when the index is lost with a git reset, that content is gone.
If the index is a commit, it can have a commit message. It can be tagged, etc.