Merging project/solution files is a well-known disaster among developers/SCM admins performing merges in their source control.
Take, for example, a common scenario:
I typically try to avoid putting automatically-generated files under SCM. Automatically-generated files should be generated from source files that a developer controls, and those can be put under SCM. If a particular tool stores data in an opaque and fragile format, this is the tool's problem.
Regarding Visual Studio, although I think it has decent compilers, libraries, and a debugging environment, I believe that the files in generates (PRJ, SLN, RC) are highly problematic. Apart from the problems you mention, they also change a lot between different VS versions. For this reason, we write our own makefiles, and build the programs externally, using make. Furthermore, we split the resource files into parts for which we are forced to rely on VS, and those we can sanely handle with a normal editor. We generate many resource files automatically from high-level description, written in custom domain-specific languages. We thus minimize the impact of changes that are difficult to handle under SCM.