It's great that 2005 has shipped. I personally enjoy using it for my own pet projects and I'm very pleased. But shipping a V2 also means exposing versioning problems in the V1 design. Such an issue came up on the forums, which basically boils down to: VS 2003 crashes when:

1. I install VS2005
2. I'm interop (aka mixed-mode) debugging
3. The main executable is some win32 (unmanaged) app.
4. That executable then loads managed code.

A common case of this would be using VS2003 to interop-debug a VB.Net COM-object, which is hosted by an unmanaged container.

Why?
The reason for the crash is very likely a collision of 2 things:
1. In the absence of any configuration settings, unmanaged apps that load the runtime will "float up" to load the latest runtime version. (This was a very difficult decision to make and there were strong pros and cons on both sides. I'm not the expert here, so I can't really comment on this decision one way or the other. )  It's important to have a completely unmanaged app here because managed apps (eg, C#) have some markings in them hinting at what runtime version to use.
2. VS 2003 can't debug an app that loads the 2005 CLR (V2)

In this case, the unmanaged app was properly running against VS2003 / CLR V1.1. The unmanaged app loaded V1.1 because there were no other runtimes installed on the box. But then installing VS2005 / CLR V2.0, meant that the app now could float up against V2. Which meant that now VS2003 was accidentally  debugging a V2 CLR.  And this lead to a crash.

The workaround:
The workaround for the crash is to just put a config file on the unmanaged app to force the debuggee to load V1.1 CLR, which is the version of the CLR that VS2003 is capable of debugging.  Config files live next to the app and has the same name but prepended with ".config". Eg, if you app is "c:\dir\subdir\MyApp.exe", then the config file is "c:\dir\subdir\MyApp.exe.config"

<?xml version ="1.0"?>
<configuration>
    <startup>
        <requiredRuntime version="v1.1.4322"/>
    </startup>
</configuration>


The significant thing is the requiredRuntime element.  I must warn: I'm not an expert in Config files and I think I've just said everything I know about them.

I believe (no promises) that the VS folks are also adding better error detection here so that it will at least warn you of this issue and advise you to put a config file down.