The ability to submit a patch directly via the version control system so that the project leader(s) can review and merge it as desired would be a great boon. You'd certainly think that SVN could be given explicit support for this feature, and I think that SVN is the best candidate given how much acceptance it has gained.
One thing that should be kept in mind with regards to accepting anonymous or nearly anonymous patches is the whole Linux/SCO nonsense. While only a project as successful as Linux is likely to gain that level of attention, it's always good to have an idea of who is vouching for a piece of code (and whether they wrote it themselves) when you're adding it to your repository.
One of my favorite features of Darcs is the "darcs send" command, which e-mails your changes to the owner of the upstream repository.
In some of my thoughts about building systems on top of Subversion, I've thought about expressing workflow through custom properties, and acting on those in hooks. So instead of patches you'd have branches, and a submission would be a flag/property on the branch that said you were ready for someone to look at it. The "ready for someone to look at it" is almost an indexing operation as much as anything.
Though another possibility might be special conventions. For instance, it would be nice to encapsulate discussions of patches in the version control system as well. Maybe a file (discussion.txt or something) could store that information. This would be like pushing the Trac database into Subversion. I'm not sure if this would work with Subversion in practice, but that's the kind of feature that could make me switch.
That reminds me of Subversion hooks -- there's a lot of power there. I don't think that's transferable to a distributed system.# Ian Bicking
I believe projects that use distributed models have been using email for that type of message. i.e. "Subject: [MERGE] ab327e678c8"