If you intend to later merge particular branch back to the central repository, you need always to keep in mind what changes you bring with it. You may already know that such merge is done using "pull request", which is that you suggest certain branch from your repository to be merged into central one. With that, every single commit done to that branch will be included.
Pull request policy, as well as commit recommendations are described here:http://www.adventuregamestudio.co.uk/forums/index.php?topic=50001.0
With Git there is always a way to copy commits from branch to branch, and even pick out particular modifications. This opens an opportunity to work in two stages: first have a "dirty" branch, where you experiment, and then create a "clean" branch, and copy only changes you mean to merge. If you were splitting changes by kind and commit them separately (e.g. one commit for solution/project update, second commit for changes in actual code), this migration can be done with much less effort.
Of course all this assumes that changing to different MSVS won't require changing the code too in some way... Then following actions depend on the nature of these changes, and whether central repository got updated to same version while you were working on your branch.
Additionally, there is an option to keep separate solutions for every supported MSVS. That may be ok for projects that rarely change project contents (e.g. add more files). But with AGS there is always a chance large piece of code gets refactored and splitted into several code files. When this happens, every project will need to be updated, which is a chore to remember (and easy to miss). Since the actual number of project maintainers is... well, currently 1,... adding extra organizational issue seem to be a very bad idea.