> I often end up putting new functionality in merge patches because it would just be hard to seperate them out. It's a bit of functionality that was forced by the combination of stuff in both branches. That's only a part of the merge - it's more like a combination patch. How do I represent that? If I put it in the merge it's hard to later recombine it (say, squash it with a bugfix). If I put it seperately, I have to leave some idiotic state in the merge.

Temporary idiocy isn't bad - you typically mostly need to examine past states to find out where a bug came from, so "building" and "not regressing" is enough. You can put a note in the commit message so nobody will wonder why the "idiotic state" is there, and put the features in the next commit.

> The VCS should track rebasing and cherry-picking. If I rebase and squash my patches, remove something specific to my branch, send it upstream, and the same changes come back at me from there, the VCS shouldn't throw up.

git rebase and merge mostly don't throw up, because they recognize when a patch is already applied, and simply skip it. I don't think you can do much better with version control support - what if upstream accidentally reverts your patch as part of a larger change or something? You would not want rebase to throw away your patch. One could argue that the assumption that git has to work well with plain patches that are transmitted by email is outdated nowadays, but I think the robustness against incomplete VCS metadata is nice.

> If I merge a change on one branch, then want to merge in another branch, I have to resolve the very same conflicts again. Why doesn't the VCS know that I merged these particular patches together already?

Git does. It's called "rerere", and I'm not quite sure why it's not enabled by default, but when it is, it automatically reuses previous conflict resolutions and presents you with a merged file you just have to mark as resolved.

> VCS need to think about patches more independently. Branches aren't series of patches - they are patch sets that change over time

Well, the basic data structure of git comes from the assumption that a commit represents a specific state of the working tree a developer actually had at some point. I think that's a nice property: It basically guarantees that when you check out a specific commit, you get what the committer of that commit had, not something that the VCS dreamed up. Of course, the committer often created that state by applying a patch or rebasing or something, so it isn't automatically a guarantee that the state is anything that actually existed for more than a second, but you can always create bad commits no matter which VCS you use.
A VCS that had patches as the basic data structure would leave me constantly scared that one of my patches would be mismanaged by the VCS so that it looked like I introduced a bug I didn't. With patch signing, you either have no more flexibility than git offers, or you risk making it seem like a patch you signed introduced a hidden back door via unfortunate interaction with a commit by the attacker.