First, some context.

.NET has the concept of a UI culture (for localization of resources) and an application culture (for the globalization of data).  This is implemented with CurrentUICulture and CurrentCulture, respectively (as a static property of both System.Globalization.CultureInfo and System.Threading.Thread.CurrentThread classes--where CultureInfo.CurrentUICulture is read-only). 

Cultures can be either specific or neutral.  A specific culture is a language culture that is distinct from other cultures of the same language, "en-US" for US English, or "en-CA" for Canadian Enlish; for example.  A neutral culture is just language specific, "en" for English, or "fr" for French; for example.  CurrentUICulture supports neutral cultures so localization of text can be performed to reasonably be sure of presenting language-correct text (e.g. "English is English" if you're in UK, US, Canada, etc.).  CurrentCulture does not support neutral cultures because it is meant for globalization of data--formatting data is a culture-specific way; which is specific to a sub-culture of a language.  E.g. the thousands separator is officially a space ' ' in en-CA but a comma ',' in en-US.  CurrentCulture does not support the concept of neutral culture because of this. 

Globalization of data is performed by a class of methods considered "format and parsing".  Examples of these are Object.ToString() (and derivitives), String.Format(), Parse()--basically anything that has an override that accepts an IFormatProvider argument.  These methods throw a NotSupportedException if you pass an IFormatProvider based on a neutral culture.

We can infer some best practices, or coding guidelines from this:

• Do not use CurrentUICulture as an argument for an IFormatProvider parameter.
• Use CurrentUICulture only for localization of resources.

Now, why doesn't .NET "really" support neutral cultures (i.e. get the point!). Well, deep in the framework (mscorlib and the BCL) there are several calls to String.Format() violating the above rules by using CultureInfo.CurrentUICulture.  What this means is, as a .NET software developer you can't be sure whether setting CurrentUICulture to a neutral culture is going to cause an exception in the framework.  The net effect is .NET does not support neutral cultures.

During my research of this general problem I uncovered a specific case that exemplifies this, dealing with MenuItem.MdiList.  Details of this have been logged as a bug with the MS Product Feedback Center as bug ID FDBK46725 and can be viewed at http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=FDBK46725.

For the general case I've simply logged a suggestion (Suggestion ID FDBK46729) to "search and destroy", if you will, any cases where CurrentUICulture is used as an argument for an IFormatProvider parameter and add a priority rule to FxCop to avoid future bugs of this nature, and can be viewed at http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=FDBK46729.