Hi,
On our demo website, I got the issue the first time I clicked on the french link. But then, even without doing anything, I just refreshed the page and didn't had the problem.
So while I can't exclude that it doesn't come from the plugin, it could well be possible that in your tests you could have done anything else other tha unpublishing the plugin and it would then have worked fine the same.
In fact, I'm not able to reproduce the problem anymore on the demo website.
Supposing that it comes from that plugin (and I don't see why it would since we didn't configure it to do anything on our demo website), you could try changing the "After initialisation" setting of the plugin. This dictactes when the plugin is run when the page is processed.
However, I really doubt it comes from that plugin. This plugin is supposed to get the location of the user based on his IP address on the first page accessed by the user and set that information in the session. Once it's set there, the plugin doesn't do anything on the other pages. It doesn't even load HikaShop.
Finally, adding a break on node removal of that javascript file should not do anything. Doing that should stop the javascript processing of the page when that javascript file is removed from the header of the page. However, there is nothing which should remove that javascript file from the header while the page is already loaded. If it were removed, it would be by a system plugin like JCHoptimize and that would be done in PHP so adding a break on node removal wouldn't do anything as that is on the browser side.
To me this just sounds like a simple issue between the template and the language switcher module/menu:
The template must have already calculated the language to use in the header before the language is switched on the resulting page. Hence you only get the correct language attribute on the pages after the first one which does the switch.