DrupalCon Baltimore: 161 sessions, many voices, infinite possibilities. Earlybird rate ends Friday.
I've noticed when the site has a non English default language, the full locale backend is used for the main D7 to D8 upgrade and also for regular update scripts.
This will just break if some of the upgrades affect the locale tables and it is specially painful since in case an exception is thrown it can trigger a new locale exception itself.
Example error messages here, https://drupal.org/node/1785086#comment-6538250
(Btw, that patch needed some tweaks itself for not breaking upgrade tests. Also js string rebuild can be triggered during this upgrades making the whole locale module needing to be kind of upgrade-safe)
How this should work IMO:
We should be using the installer locale 'st' for both, D7 upgrade and other module updates for the locale module to be able to upgrade its own tables if needed.
Also now we have an abstracted locale storage, we could switch the storage using a safe one during these operations. So my suggestion would be just dropping st() function and make t() and locale module itself decide on the storage to use. This would also make life easier for module developers since they won't need to make the distinction for update-safe code, which is not as obvious as it seems because many functions besides the ones in .install files can be triggered from that operations.