Practical Limitations With Assemblies Not Marked As CLS Compliant?

As an OSS library author, I've always tried to make my stuff CLS compliant. But MS doesn't make this easy. They often put you in catch-22 situations, such as the following:You cannot have a protected variable differing only in case from the public property.You cannot have protected or public variables starting in an underscore or 'm_'. If you want to make a class really extensible, you often need to have protected variables matching public properties. Your least ugly exit is to add a suffix to the variable, like "Var" or "Value". That's nasty and unacceptable to me. I like clean code.I know of no .NET languages that don't support variables starting in an underscore, and I've used them in many places where the variable needs to be visible to subclasses.

I'm tired of the warnings, and I'm planning on turning off CLS compliance at the assembly level on my 30+ C# libraries.Are there any actual problems with turning off CLS compliance on libraries? Any real problems with doing this? Microsoft has issued unheedable guidance on software for decades, with less that 5% of it being worth the bytes it was encoded in. I can't find any evidence that this best practice has any real effect on anything. But, to be careful, I'm checking. And no, this is not a duplicate of the inverse of this question: Any reason not to mark a DLL as CLSCompliant?I'm looking for actual results and effects here, not the advice of a MS intern. For example, if IronPython, IronRuby, or F# are unable to read or write a variable starting with an underscore, that's an effect, although it would only cause a problem for users subclassing certain objects. If a language or tool is completely unable to use an assembly unless it is marked CLS compliant, now that's a big deal.