However, if any of these approaches are done, the operational complexity will be immense, and latency for requests much higher than they could have been. A lot of message passing would be required to build such an architecture, and a lot of bandwidth would get wasted, not to mention the unnecessary costs.
A simpler approach would to store core business data regionally, but peripheral data everywhere. For example, a todo app would store all user records, project lists, and other data everywhere, but the actual todos regionally. And yes this becomes infinitely complex will collaborative cross-region applications.
I don't think there are any good solutions yet to this, and governments should invest in creating better solutions before forcing to go down this route.
But that's rare. Generally the data lives on a regional server and gets accessed by a CDN in a region near where the data will be delivered. If you're allowed to sign in from that region, then you're likely authorizing transfer of data (for the duration of that session) to that same region.
As for multi-region replication, it's often the case there are multiple regions in the same country - for example, us-east-1 and us-central-1. No jurisdictional problems to host the data in two regions in the same country, after all.
As to how you look up what region the user's data is stored in, well, you can keep a list of users and regions. Worst case, force the user to remember their region, and use separate copies of the website (and DNS) to pick a region to sign in on. For example, the same app/website, but at different country domains.