And while we are at it stop tunneling my data back "home" when I travel. I don't want increased latency.
You might not, but a whole lot of customers who aren't as technically sophisticated did. When T-Mobile first started doing included international data roaming, they didn't tunnel back. That caused a lot of confusion from customers who didn't realize why stuff they expected to work, like checking their bank balance, didn't. (It also made throttling speeds a lot more difficult.)
So to fix that, T-Mobile tunnels you back to a few endpoints in the States. Banking apps are generally happy, as are Netflix and Spotify. Most customers are happy because their phone "just works" the same as it "always has".
For those of us who want to avoid the latency, we get a local SIM for data (if possible).
The only thing I can think of, assuming they tunnel as you describe, is maybe I first loaded the site from local WiFi instead of mobile data, at which point I was redirected (to a localized subdomain that doesn't redirect back) or got a cookie or something, which lingered as I continued without WiFi.
Oddly enough, I found this to be a plus when I traveled to China for work. My data was unmolested by the Great Firewall of China. I was able to get on websites with my mobile data that I couldn't when using wifi in the hotels.
Not if you need to send a message to $thatUniquePhone.
Over simplifying considerably, but if a land line places a call to a mobile, the "220-1234 calling for 220-7890" message enters the network. The `220-7890` phone number needs to map to the unique modem address so you can look up which tower the call setup data should be sent to. If - by sheer coincidence - I also have your MAC address and am attached to a tower 3 states away... which tower(s) do you forward the call setup data to?!
Whichever one has most recently communicated with the user in question (based on the credentials or certificate provided, in the original example)
If you have a wired connection, this makes the MAC completely superfluous. The concept is sort of still valid for wireless connections (or of course for "wired" connections where you have multiple devices physically connected by the same wire, a bus, where the concept originated). It should be rethought.
Note that this is only about last-mile/first-hop. Once you scale past a single LAN segment, routing is mostly layer 3 until you get to core Internet infrastructure which uses ASNs and BGP. At the very least, it is probably sufficient to say that routing across a WAN is all about IP, but if you zoom in on parts of that network of networks, the underlying technologies often use other routing mechanisms internally that don't get exposed to the other parts of the WAN.
It’s also worth mentioning SLAAC does not strictly require a hardware address to function. For example, Apple devices implement newer standards from IETF to generate random but stable addresses that don’t reveal information about the hardware addresses (https://support.apple.com/guide/security/ipv6-security-seccb...)
The phone could pop up a menu saying "Here are the available networks", and you pick one, connect and it says "Welcome to AT&T, enter credit card number here", and you type a number and hit OK and you're connected.
Oh wait - just like Wifi!! Why are mobile networks so far behind?