The relatively coarse-grained nature of generic constraints in C# / the CLI is my biggest annoyance with the platform. There's really no reason why the compiler couldn't infer method (and operator!) and property level constraints and simply require that all type arguments provide them.
As far as I can tell, the reason C# generics have the limitations they do is because they can be deployed in DLLs. This means that the compiled generic must work both for existing 'T' as well as unknown types that someone may cook up in the future (as long as those types fulfill all of the constraints the generic specifies). The compiler ensures that the generic can be used by anything that supports those constraints, without needing to actually be instantiated like C++ templates.
This is both their greatest strength and the cause of all of their weaknesses.
Though there is another potential design decision that would enable this, which would be to allow interface implementation to be implicit. For example, if you're like me and wanted to write a generic structure that does math of some kind [for example, a vector class], it'd be nice if all you had to do was specify that said object implemented an interface that exposed an add, multiply, divide, and a negate function. The compiler can infer the existence of an interface that has these properties simply enough [or maybe even demand that you implement the interface to make it additionally explicit]. The missing link is to be able to take a type, notice that it has an add, multiply, divide, and a negate function, and deduce that it implicity satisfies that interface.
In fact, the lack of this, and the lack of explicit extension-method style fitting an existing type into a new interface, is what really prevents things like generic matrix classes. This is entirely do-able though, and is something you can wedge into a DLL without much issue.