How to explain Git's Index to a Subversion/CVS/Mercurial/etc user

One thing about git that consistently seems to puzzle or scare off new users is the index. I, in turn, am puzzled at this puzzlement, because every version control system I've ever heard of has something similar... it's just implicit and therefore not as easy to deal with. In CVS or Subversion, when you do an 'add'... what are you adding that new file to? It's not checked in yet (you haven't done a commit). The answer is the implicit index I was talking about. Take that minor little feature and expand it. Note the minor inconsistency that if you were to add a file and then change or delete it, the state gets.. inconsistent. To solve this, and add more functionality in the bargain, what if when you do an add, the system were to store the file _at the time you did the add_ and be ready to commit *that* version when you did the commit? That way it's always exactly clear what is going to happen when you do a commit, and also since all modifications have to be re-added, you've got a nice way to separate out changes in the working copy you want committed from those you don't.