Magento – Setting product price per country while avoiding store view over-duplication

I'm currently working on a multi-country, multi-language solution using Magento 2.
I'm having trouble (especially with performance and somehow with maintenance) configuring such a store.

Let's consider I want to create the following site hierarchy:

• International website: example.com
• United States store: example.com/us
• Canada store: example.com/ca

Now let's say that I want the U.S. store to be available in English and Spanish.
I'd have something like example.com/us/en and example.com/us/es.
I would do the same thing to get the Canada store available in both English and French.

I also want to configure my products as such:

• The whole catalog is shared across all countries and each country store enables or disables products in this catalog the way they want. It contains about 3,000 products, most of these being simple products and a few being configurable.
• Each country defines a different, fixed price and possibly a different, fixed currency. As an example:
  • If you're living in the U.S., my awesome product costs USD 100.
  • If you're living in Canada, my awesome product costs CAD 80 (regardless of exchange rates).
  • If you're living somewhere else, you get the international price, which is EUR 150 (again, price and currency are fixed, and rates are irrelevant).

User country is determined as soon as you enter the website using IP location and CDN services.

As far as I understand, I should go with the following structure:

Website     | Store   (Catalog)         | Store view
------------+---------------------------+-------------------------
Int'l       | Int'l   (Default catalog) | English (United Kingdom)
US          | US      (Default catalog) | English (United States)
US          | US      (Default catalog) | Spanish (Mexico)
Canada      | Canada  (Default catalog) | English (Canada)
Canada      | Canada  (Default catalog) | French (Canada)

So far, so good, as we only get a total of 5 store views.

The thing is the real store I'm working on requires fixed prices for more than 20 different countries.
All country stores are available in more than 10 languages. These languages are from the same set, e.g. our previous example would have all 3 stores available in English (UK), English (US), English (Canada), French (Canada) and Spanish (Mexico).

Counting from this, I would already have 200 different store views with this kind of setup.
Each new store I would create afterwards would have to be immediately available in my 10+ languages.
Each new language I would add afterwards would have to be immediately available on all stores.

While generating front-end views from cache may still be quite fast, (mass-)importing products and generating indices at that point is just slow and unreliable.

I also have a lot of CMS content which happens to be the exact same for every country. For example, I have a page "About us" which is translated in all my languages but has the same content wherever you live. If I create a new page, that means I have to make sure that each translated version exists in all countries. Once more, if I create a new country store, I would have to make all my CMS content immediately available on it, making the process difficult for regular back-office users.

At the moment I don't even know which way to explore to get a decent configuration.

To sum up:

• I need to be able to define a different, fixed product price per country.
• I need to have all my country stores available in a defined set of languages.
• I need to be able to link CMS content to all country stores.

With my colleagues, we thought of several approaches:

– Using configurable products

Products would be set as configurable. Each variation would actually be the same product with just a different price.
It gives an easy product setup through the back-office, but does not allow different currencies. It does not solve the number of views issue, as we would still have to define one website per country to be able to manage products as enabled / disabled.

– Using user groups

Creating one group per country then assigning pricing rules per group sounds great. We'd just have to make the country a required field in a registration form. However, it means we cannot handle prices for non-logged-in users (unless it is possible to assign groups to guests?).

– Splitting into continent-based magento installations

In such a case, let's say we would have something like two magento installations for Americas, two for Europe and another one for Asia. It should solve most performance issues like in North America having about 30 views (still, we're not sure it would work in Europe). It should solve maintenance issues for back-office users in the same way, considering we can create some sort of gateway to import CMS contents on all installations; the bad side being technical maintenance issues, especially to deploy security patches / bug fixes in a timely manner.

– Tweaking modules / templates to get a single store view per website

Based on answers found here (https://magento.stackexchange.com/a/19741/243) and there (https://magento.stackexchange.com/a/52937), we could tweak store views so that we would have:

Website        | Store     (Catalog)           | Store view
---------------+-------------------------------+---------------------------
Int'l          | Int'l     (Default catalog)   | Store view (10+ languages)
Country 1      | Country 1 (Default catalog)   | Store view (10+ languages)
Country 2      | Country 2 (Default catalog)   | Store view (10+ languages)
...            | ...                           | ...
Country n      | Country n (Default catalog)   | Store view (10+ languages)

It seems to be our best option but as the second linked answer suggests, going against the regular Magento workflow may be costly. It may also conflict with third-party extensions.

We've also looked for extensions but all the ones we reviewed were about having product prices defined on store views, which means we still have to define <countries * languages> combinations.

I'm open to any solution or lead, whether it requires specific development, configuration or using third-party (even paid) extensions.

Thanks.