This is kind of a loaded question, but I really hate when people remain super vague and try to sound all intelligent about a topic, so I'll try to write out my plan with a few thoughts. It really depends whether you're working on a variety of different types of servers, or only a single type. Also, if you're fiddling with provisioning for some reason or another, this could increase the need for a per project basis.
For me? I Like things in templates: Code, life, budgets, shopping lists, frying pans, etc.. I am an engineer and I like things abstract and generalized that are reusable and extensible.. So for vagrant, I'd want one primary vagrant project repo with the provisioning tool I prefer (puppet). I would have different versions of this abstracted and generalized as I saw fit per project. If my company did hundreds of wordpress sites, i'd make a default setup that started up a server and installed the latest (or x) version of wordpress, and similar for whatever other projects that aren't rarities (Symfony, RoR, Laravel, node).
When starting up a new project, you would initialize the new repo for your project, and then add a submodule for the closest generalized vagrant project for your needs. Developers could then edit the vagrant submodule, and either not push changes, or push changes if they were large enough changes to require updating.
I would be sure that developers who had a need to update their vagrant repo did so by creating a new branch. I would have git hooks on the vagrant repos that notified lead devs of changes, so they can review and determine necessary steps for further abstracting out projects. Can we create a new vagrant repo based off the changes for this specific project? Is it important enough?
This flow should ensure we can have control of our git history for the sake of reviewing projects in the future to determine their "base" vagrant setup, allows us to easily update and correct any bugs that existed in our base vagrant projects, and allows all projects to be able to update their vagrant submodule's easily without impacting their project code.
Anyway, that's my idea for how I plan to do it if I ever get around to it.