I did it. I found a bug in VS2008 RTM. I'm sure it will not be the first nor the last, but I found one. I'll get to what it was in a moment, but first I want to say that I am really pleased with microsoft at the moment. I finally found the place to go to submit a bug. What amazed me most was that I actually got a response within HOURS! The response actually included a test project where they couldn't reproduce what I had submitted. I simply cleaned up their sample and resubmitted it, showing exactly how to reproduce the error.

If you're curious about my submission, here is the link:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=315555

To Submit bugs about Visual Studio in general you can go here:
https://connect.microsoft.com/VisualStudio

The Error
When debugging javascript in the script explorer and you have multiple javascript filenames that are the same, a breakpoint set on one of the last loaded files moves to the first loaded file upon page refresh. For example, say you have an aspx page that includes several script resources in the form of webresource.axd requests. You want to put a break point into the last loaded webresource.axd. This is all great until the page refreshes. The breakpoint will move to the first loaded webresource.axd on the same line. This is really a pain when you are trying to debug an onload handler, because the break point moves and doesn't get hit.

Of course, you can avoid this all together if your scripts are local, which is really a better idea in general because IIS will handle cache expiration for you since webresource.axd is not cached. (I know this was the case for .NET 2.0, however, they may have changed it in 3.5. I just haven't tried it yet - if you know the answer to this, please leave me a comment!)

Anyhow, another caveat that I ran into was actually setting the breakpoints in those dynamic javascript files. It doesn't appear to load the js in memory initially. It takes a few seconds, so just keep pressing F9 to add the breakpoint... It will eventually load and insert the break point. As a side note, when it doesn't insert the break point you will see "This is not a valid location for a breakpoint" in the status bar - don't worry, just keep pressing F9.

I found a good example of when not to try to use generics.
I was obviously back in my C++ mindset when I tried to do this:

public class Test
{
private void Func(string s) {/*do something*/}
private void Func(int i) {/*do something*/}

public void GenericFunc<T>(T t)
{
Func(t);
}

public void main()
{
GenericFunc<string>("String");
GenericFunc<int>(1);
}
}

This (should) produces the nice compile errors:
CS1502: The best overloaded method match for 'Test.Func(string)' has some invalid arguments
CS1503: Argument '1': cannot convert from 'T' to 'string'

The reason I was trying to write this code was to reduce the amount of code I was writing. I had inconviently consolidated several functions that did the same thing into one Generic function, however, there was one specific difference for each method - the call to Func(Type) which was radically different between types. So even though I had declared the functions for which I was using, we get a compile error because .NET requires generics to be fully generic. Converting the syntax to C++ and compiling as c++ would result in a happily running piece of code.

Here is the SDK documentation for it:
Differences Between C++ Templates and C# Generics (C# Programming Guide)

Reading the last key point: