At best, the design and maintenance of application across versions is something we should be constantly considering. However at times versioning issues can be monumental to overcome. For the most part, it's pretty easy to write an application (and a set of few dependencies) and deploy them and have them work properly. If redeployed completely autonomously as such versioning isn't too much of an issue - you're always shipping the entire app. However, taking such an application and then upgrading it piecemeal can be a bit tricky - though not always very difficult. Where it gets more complicated is when you create a reusable component that the designed to function as an API or as a third-party component in another application. Other applications, outside your control, may begin to rely on the objects within your libraries / assemblies.
The concept of assembly versioning is not new by any stretch of the imagination. We've dealt with some interesting and complicated versioning issues in the past, most memorably COM's notorious DLL Hell. For many .NET's versioning model was seen as a much-needed reprieve from the world of COM. With .NET, the assembly's version is baked into it's name (consisting of name, version, culture, public key). With this key bit of information so accessible, the .NET runtime can load the appropriate assembly and bind to it (it can, of course, be overridden and forced to load an alternate version via policy (config binding or publisher policy)). This luxury did not exist as such in the COM days. With COM you only had one component (.exe, .dll, .ocx) on your machine representative of all versions - that is, all dependent applications would ultimately attempt to use the single version. This would lead to applications expecting behavior to be present that might not exist, perhaps because the correct component was replaced by another application's not-so-friendly installer.
Despite the progress made from COM to .NET, we're not completely out of the woods - but there is light at the end of the tunnel. It's nigh impossible to create a silver bullet that will solve all versioning issues. However, Microsoft is putting a lot of thought into issues that revolve around versioning. If you haven't read this article, I encourage you to do so - there's lots of cool stuff being considered. Of course, there's no guarantee that any of this will truly see the light of day, but I really like the direction they're going. I am particularly excited about notion of Platform Assemblies and Library Assemblies and can see lots of benefits.