The only way I think you could address it in retrospect would be to have separate launches for US and international — or at least separate allocations (using registration data from interested users and traffic before lead up to help make estimates on demand) of units, say 15,000 US units and 5,000 international or whatever, depending on how you want to mix it. That isn’t a perfect solution either and you can either over or under allocate, but it would probably appear to be more “fair” to international buyers.
But lbr, anyone buying stuff like this internationally is unfortunately always on the losing end. The same is true for US buyers who are after stuff primarily shipped in Europe or Asia or Oceania. It is unfortunate, but until you have the scale to truly have separate international storefronts and sales teams, people outside of the main market are always going to be lower on the list.
I'm uniquely positioned to talk about this as I provide a free Shopify Shipping App that I'd imagine would use the same APIs as the "third-party international shipping plugin" you talk about.
Shopify has identified 3rd party app server capacity as an issue with "flash sales", and this is why they've been throwing a bunch of dev time in getting web assembly to run out of the browser and on the server. Their aim is that they'll run the App's code on the app dev's behalf. Web assembly was chosen for sandboxing.
Here ends my knowledge!
Or are shipping and tax rates so complex, and there are so many different ones (depending on state/province) that it's stricly impossible to do this without a plugin?