Using git submodules doesn't imply you're doing something correctly

True, but you can't do this correctly without them, or something else that tracks which versions all the plugins should be on against each commit in the containing repo (e.g. the ~/.vim folder). If I roll back to last year, I need 60+ plugins to go back to where they were at that exact time, and many to go away, and others to reappear, and to have all the mappings in my vimrc match up with that time, too, and my custom ftplugin, after, syntax, color, etc overrides to also match that time. I've heard that Vundle lets you freeze versions by mentioning a version, but then to get things to be correct, you have to manually freeze every plugin every time you update it, and commit that freeze with your vim repo. That would be the same idea, but far more involved.

There's another aspect, though. Vundle users love that they can fire off one command and have all their plugins update, but this is also a broken model. It might work out okay, but that's only accidentally, because we are just talking about Vim plugins here, and the plugin writers try to keep breaking changes to a minimum. However, breaking changes do happen (see powerline changing its entire model out from under me, prompting a switch to airline), and tiny changes occur, often in mappings (simple example: tpope changed the diff splitting mappings in fugitive at one point, and a bunch of people harrassed him about breaking it, because they didn't read the commit changes; they just auto-updated, and didn't understand what happened. The right way - and you can dislike this, but you can't argue the correctness of it - is to scan at least the commit changes to see if anything will break, and then fix your containing repo's ideas about that submodule when you update to it (e.g. I fixed my mappings against tpope's change to fugitive because of that commit). If you don't, and something you didn't expect changed, at best you have things that work oddly, and at worse (in the case of Powerline), you'd have a plugin that was completely broken.

Are you saying that you are modifying the plugin itself?

I have, but very rarely, and I usually try to push the change back up, so I don't have to maintain the patch myself, and so others can benefit from the fix/upgrade/whatever.

By editing your configuration to remove, replace, create mappings, etc you're not needlessly modifying a project and potentially creating conflicts for yourself.

Right. My issue isn't custom mappings; it's not versioning your custom mappings along with the state of the plugin(s) at the time those mappings were made. I think most people version their vimrc, but not their plugins, so if they rolled back to 5 months ago, they'd have a ton of breakage. They'd possibly have mappings in their vimrc for plugins that their versioning didn't resurrect from a later deletion when they went back. They'd possibly have plugins from later times conflicting with mappings from back then. They'd have mappings for states in plugins that didn't exist in those plugins back then. And so on. This is my only point. Versioning your vimfiles without versioning the plugins they interface with in perfect lockstep is a half-solution to versioning your vim experience over time.

For me, I'm not too concerned that some plugin is going to break or create a new feature.

Statistically speaking, no one who's ever existed does :)

I suppose the key difference is that I, currently, use 24 plugins (a few of those are just colorschemes). So, Vundle works perfectly.

Yes. In fact, if you have no ties between your vim files and any of your plugins, you can throw out my entire argument. There's no temporal connection between your vimrc, ftplugin, autoload, syntax, color, after/*, etc files and anything in your plugins. If, however, you have a mapping in your vimrc that twiddles a thing in a plugin (opens something, uses its functionality, whatever), and you're not versioning things such that your changes to the vim files, and the changes to the plugin stay locked together in time, then you have a hole in your versioning. The problems this can cause are usually really small (it's just a text editor), but it's still not 100% correct, from a historical perspective. I lived this way for a long time, and then I felt like checking out an old version of my vim setup, and all hell broke loose. That showed me that I wasn't keeping accurate historical records. Now I have been, and if I go back 3 years ago, everything works fine the way it did then, because plugins go away, old ones reappear, and everything checks itself out to the state it was in at that time, along with the mappings and plugins that worked with those states at that time.

If there were to be an issue introduced into some plugin (which I haven't really encountered), then I would create an issue (possibly a pull request) with the project on github.

This is not the same thing at all.