I've got some fun LINQ-related discussion to post soon, but I thought it'd be good to add a bit of a wrap-up to the last discussion here about overload resolution.  I was happy at first having verified that our behavior matched the spec, so I moved on to various other things.  However, the customer who brought the issue to me in the first place was unsatisfied with this response.  He wanted to know the reasoning behind the behavior, not just that we had documented our behavior correctly.  Thanks to Jeffrey Sax for raising this issue, and hounding me about it until I delved deeper and really thought about C# language design.  Since much of my job involves verifying the compiler's behavior against the spec, it's easy to forget that I also need to be continually evaluating that spec and the decisions we've made in the past.  His blog post on the subject is a great read and highlights both the design principles behind the decision to prefer more derived methods and some of the problems with it, so I won't go into too much detail, but if you read my previous article on overload resolution, I highly recommend it.