Interestingly, I am researching this for a customer. Another way to do this that I have seen is to seed the ID counter at the site to a really high number (e.g. set ^Vendor.CountryD=10000000) after the initial Country code table is deployed. Then, new entries that are distributed by the vendor will never have conflicting IDs (assuming no more than 10000000 entries are ever shipped of course). But this also means that you can't ship the whole vendor copy of the global as you will overwrite the onsite ID counter node.

And, in a multi-tenant/namespace deployment you can't generate SQL or Object Insert scripts - if you have indices on the table then they need to be built locally for each namespace and global mapped and so you would need to run the insert script on each namespace to maintain the indices. However, rebuilding the indices on code tables should be pretty quick as they tend not to be huge, and hopefully won't balloon the journals too much....

I like the idea of a read-only distributed database - oddly I hadn't thought of that as an extra layer of protection beyond what the application code may provide

The biggest issue with this approach though is  likely to be the risk of a unique property collision - customer adds MYNewCountry , and then at some point so does the Vendor. And so an upgrade script would have to check for that - possibly renaming the customer object to say MyNewCountryX.