Well, I sat through all 3.5 hours of this presentation and it was worthwhile overall, although some guidelines did make me wonder if they were only applicable if you have 10million users and want to minimize breaking changes.

Specifically guidelines like:
Prefer Abstract class over Interface, Minimize use of virtual modifier and Prefer more restrictive scope than public. I do agree that all of these are great ways to enable easier evolution of an API in later versions but they can hinder Unit Testing and Mocking.

Is it really such a big issue to have a breaking change or to modify an interface in a new version of an API ? Yes clients will have to do some (less == better) work in order to become compatible with the new version, but they presumably don't have to upgrade instantly. I suppose it depends on how generic or low level the API is, or how frequently it is extended in applications.

Anyway, other bullet points:

• Create - Set - Call Pattern: Anti OO in a way, and initially driven by drag drop mentality, but it is a consistent pattern in the framework.
• Consider Intellisense ordering when naming methods (not to the detriment of good naming though).
• Use least specialized types as parameters - eg use of IEnumerable<T> for collection parameters allows caller to pass array or list.
• Implement IEquatable<T> on Value Types.
• Namespace factoring: Try to put advanced scenarios in deeper namespaces.
• Catching an exception and then doing throw; still unwinds the stack, hence debugging doesn't work properly and it is better to not catch at that point without more reason than logging.