For BC SAAS scenarios. In my background I did not have to deal too much with country localizations and can do with advice of consultants more experienced in that space.We can have a tenant with companies requiring different country localizations. My take is that the multiple country specific localization extensions can be loaded. It seems that the tendency is to provide setups in the company setups, so that specific country localizations can activated or deactivated. I noticed that on Australian localizations.Is this about the common practice on all official localization extensions? I want to try to make sure that various localizations will not cause conflicts for a global rollout installation containing companies in many regions.It is not all about setups, I know. We already came across something as simple as the Company Registration No. field that cannot be personalized back onto Company Info Page and probably will have to get it back by adding an extension.
I wrote about this back in April 2018 in my blog https://dynamicsuser.net/nav/b/admin/posts/global-implementations-with-dynamics-365-business-central - but sadly this is not really where Microsoft are today. They still use localized base applications, only new countries and new localization requirements are created as extensions. But something as fundamental as VAT is also very often localized, which is done in the base application. It is still a long term goal, but nothing they priorities as far as I can see.
So as of today May 2021 the way to have a setup with a Azure tenant per country. You can have multiple companies from the same country in each database, just as you can on-prem.
The One Database Core Model I describe in my blog post is not really possible today in the cloud.