All versions of VBLM prior to V6 extracted and maintained a single copy of each unique string found in the parent VB project. While this meant that you only had to translate each string once, it also meant that you had to jump through awkward hoops in those not-infrequent cases where you needed to a) provide multiple translations for the same string, or b) translate some instances but not others. No other aspect of VBLM generated as much user grumbling as the downside of single instancing.
While VBLM still maintains only a single instance of each unique string extracted from your projects, it also maintains separate translations for each instance of each string. Thus, while it remains effortless to translate all instances identically, it is equally easy to translate all differently, or to translate some and not others. Moreover, there is no more build-time decision making about which translation to apply to different instances.
This change may sound trivial, but it entailed a fundamental change in VBLM's basic structure and function and a complete rewrite of the code into a much larger and more complex application. VBLM now keeps track not just of which strings occur in your code, but where they occur. Doing this once is relatively straightforward, but keeping track over time as your code changes is not. Moreover, strings can no longer be handled by themselves, say for importing and exporting -- each string must now be accompanied by its context, ie the line(s) of code in which it occurs.