I'm not sure if people realize how significant the fixing of the Excel locale issue is that I blogged about earlier: http://blogs.msdn.com/eric_carter/archive/2005/06/15/429515.aspx

This has been a huge adoption blocker for writing managed code against Excel that has been mentioned repeatedly by customers, books like the recent one by Stephen Bullen, and others.  We now have behavior in VSTO that makes developing in managed code just like the VBA experience--the locale is always kept at 1033 so your solution will work as expected in other locales.

We now expose as new Microsoft.Office.Tools.Excel.ExcelLocale1033Proxy.Wrap method to which you can pass the Type of the object you want to wrap and the object itself and get back a wrapped object that will always talk to Excel in the 1033 locale.  You can use this if you ever run into a case where you get an Excel object that isn't using the ExcelLocale1033Proxy and you want to force it to always be kept at 1033.

public static object Wrap(Type typeOfObject, object excelObjectToWrap)...