Hi @PawelP.
I appreciate you putting in the time to show your findings when composing your question. My projects have never really needed anything more than to support en_GB over en_US. I know there are plenty of stores out there that support multiple languages… So, my experience is somewhat limited. But I’m happy to share what I do “know”.
Like you, I’ve had to make similar changes to my projects. Compared to M1, M2 is very compartmentalised, which is a good thing. The bad part is having to work it all out 
My favourite fact about the new translation system is that it’s now referred to as “i18n”, which is short for “internationalisation” (“i” followed by 18 letters then “n”). I don’t know why I find that so cool…
i18n locations
Anyway, being too lazy to research i18n in full because I’ve never had to do any “true” translating, I stumbled my way around. But this is what I’ve learned so far:
- i18n can be initialised in the child theme just as you mentioned.
- i18n can also be initialised per module within
app/Vendor/module/i18n/ - Some labels are hard-coded in and can’t be translated via 918n (A side effect from lazy coding)
Based on the first 2 points (above), here are some examples of where i18n files can be initialised:
app/code/Vendor/module/i18n/app/design/i18n/-
vendor/vendor/module/i18n/(Never edit anything in this folder)
Because there are essentially 3 locations that i18n files can be initialised from, Magento always checks the app/vendor files first. Then it checks the app/code and app/design files for any overrides.
One thing I don’t know is what takes priority out of app/code and app/design. Perhaps you can tell me?
i18n caching
i18n “technically” gets cached in 2 locations, one of which is the standard cache which can be cleared in System > Cache Management. Fairly obvious I know…
The second location is the generated static files. I learned this the hard way, believe me… Sometimes I would update i18n files and get frustrated because I couldn’t see my changes. Even after updating several files in several locations. In the end I stumbled across this.
When I redeployed my static files, I would have to specify both the default en_US and the en_GB languages. The commands vary slightly depending what mode you’re in:
-
(Production Mode)
bin/magento setup:static-content:deploy en_GB en_US -
(Developer Mode)
bin/magento setup:static-content:deploy en_GB en_US -f
Even though I only support en_GB, I think I still have to generate en_US because that’s the default fallback language but I could be wrong.
Anyway, whenever I make an i18n amendment I always run that command before previewing it.
Existing en_GB language pack
As a starting point for creating an en_GB language pack and essentially “reverse engineering” it, I use this module via composer. This module should give you everything you need in order to create your own language pack from scratch (including the basic files required to build a module).
I was too lazy to make my own pack from scratch, but there was still some translations that I wanted to tweak. So I broke rule #1 to achieve this and edited the core csv files in the module. Which means that if this module is ever updated, it would write over all of my changes. But I still did it anyway because I have backups of those files and the chances of this particular module being updated are slim. Practice what I preach not what I do
Summary
I’m not sure what else I can share with you as I clearly have some knowledge gaps in this topic. Hopefully, you’ll be able to either use or reverse-engineer that module I shared. And you should find that static-content command helps as well. If you learn anything else along the way, please share as I’d like to know.