There is a race condition somewhere in System.Resources.ResourceManager of .NET 4.5 (it's probably present there from 4.0).
The race condition leads to internal cache corruption that prevents proper resource fallback. The easiest way to get this condition is to try to get a resource that does not exist in one of the localized versions, using specific culture ("language-COUNTRY"), so the fallback mechanism is triggered. The expected behavior is that getting the string that exists in the "base" version of resources (Resources.resx) would work no matter what culture is used in the request and what other extra resource files (Resources.<lang>.resx) are there.
With single-threaded versions of the code, it works both for private or shared resource managers. Unfortunately, multithreaded versions lead to missing string value, permanently "damaging" the resource manager in shared case and affecting only one copy of the manager in the private case.
Since the bug manifests itself even when ResourceManager instances are not shared between threads, it appears that the race condition does not lie within ResourceManager itself, rather it is located somewhere deeper in the framework code.
While it is unlikely to be triggered in GUI applications, we observed this bug manifesting itself on ASP.NET web servers leading to incorrect resources being used by the website, until the application domain is recycled. We are not the only ones with the same problem, for example check http://stackoverflow.com/questions/17652351/.