If I've not mistaken, that uses lstricmp internally for comparing keys.
It uses lstrcmpiW, which according to MSDN can behave differently based on locale, but I don't think the Wine version does.
The comparison is in the propertyNameCmp function.
I think that the MS storage code probably does something else.
PS looking at code one more time, current code seems already depends on "lstricmp working same" [in updatePropertyChain()], so already broken. It's pure luck that it is not failed already.
Well, yes, now it just depends on it even more (we'll fail reading files too instead of just writing invalid ones).
I've checked the compound file spec from MS and the one from OpenOffice. Neither of them specify the comparison beyond "character by character
I think what saves us is that programs rarely expose storage and stream names directly to users, so the set of characters we have to deal with in practice is limited.
Still, we really should use a comparison function that's at least guaranteed to be consistent.