After reading through the two linked pages I can not see the relevance. The first article just discusses the in-place update but shows no (real) problems with that. The problem in the Stackoverflow question turns out to be caused by a bug in the OPs code and not by a breaking change between versions 4.0 and 4.5. Of interest may be the linked list of breaking changes [1] and given the size of the .NET framework it is a very short list.

[1] http://msdn.microsoft.com/en-us/library/hh367887.aspx

Note: The deleted comment was something like »This is not true«.

Even if there was only one issue, that is an issue to spend effort working around it if you're the poor soul that needs to do the fix for the product that broke.

I am still unable to see the problem. It's your decision if you switch to 4.5 or not. If you have projects targeting 4.0 and are unable to ensure that you code does not hit any of the documented breaking changes or if you are unwilling to take the risk of hitting unknown or undocumented compatibility problems, then don't switch to 4.5. Or take a hybrid solution - develop against 4.5 but test against 4.0.

We have deviated quite a bit from the original comment - you can install different Visual Studio (and .NET framework) versions side by side if you have to support legacy projects. There are some case where this will not work - obvious examples are .NET 1.0 not being supported since Vista, .NET 1.1 since Windows 8 - but there are still a lot of cases where this works just fine. If an side by side installation is not possible, you can still just setup up a second machine or a virtual machine for you legacy development needs. Not being able to upgrade Visual Studio because you have to support legacy projects is mostly a non-issue.

In our case teams that are supporting .NET 4.0 are not allowed to upgrade for .NET 4.5, precisely because of the .NET 4.5 bug fixes that lead to different behaviors between versions.