People shouldn't need to be tied to any physical address. A virtual address should function perfectly well. This can be in the sense of a nomadic tribe, the homeless/dispossessed (of which there are far too many right now) but it can also be in the sense of the Donald Coxeters of the world, people who simply don't have conventional lifestyles.
(For those unfamiliar with Donald Coxeter, I strongly recommend learning some maths. Any maths will do.)
So what you need is a virtual address that can map EITHER to a physical location, OR a logical location (such as a tribe), OR a transient address (see the 1996 specification for IPv6), OR an Internet address. Since you want to leave room for expansion, I recommend using at least three bits to specify the address scheme.
IPv6 isn't long enough for this, although the concept is correct. The concept is that you have a prefix that tells you what you're doing, a routing segment that tells you where you're going, and a suffix that is absolutely guaranteed unique and allows you to transition to absolutely anywhere in any form without losing anything along the way.
You can't route parcels over the Internet, you can't route multicast packets by mail, so clearly you need a protocol type in there as well. There are something like eight packet-based protocols. If we leave room to expansion, you need four bits to identify the type of packet, two to identify mode (unicast, multicast, anycast, plus one spare) and four bits to identify layer 1 constraints (what you can't send over).
That's 13 bits to define the characteristics of an address. That's three bits reserved for future use to round it to 16 bits, or two bytes.
Because this scheme is independent of user and is just as valid for probes in the Kepler Belt as for people on Earth, we're going to need a more sophisticated prefix. It's hierarchical, so all routing is as local as possible. Which is great, if you can be certain of never having more than 256 downstream next hops and one upstream hop. Not really viable if part of the intermediate system (people on aircraft, trains, other planets) is ad-hoc, because you simply don't know the topology. (Yes, I'm assuming here that Joe Bloggs' laptop on a 767 can become a relay point for any packet from any source to any destination, if that offers the best routing metric for that packet.)
You need a routing strategy that guarantees that two unique endpoints can communicate over any/all multipath lines of communication by best method possible per packet. Here, IPv6' hierarchy is not so good. It assumes one path from start to end, even though the path can change without notice. Packets midstream are supposed to be redirected.
For computers, that's tolerable. For postal mail, not so much. For postal mail to a mobile endpoint, it's too expensive and risks routing loops. For anything else, it's a disaster.
The good news is that people have dealt with weird network topologies in computing and graph theory for a long time now. The bad news is the computer geeks doing this aren't interested in ad-hoc (not much call for it in supercomputing or anywhere else butterfly networks and hypercubes are used) and mathematicians aren't any further along than static coloured Petri nets. Dynamic networks aren't yet at the bleeding edge of technology.
Not to worry, if we layer an ad-hoc routing strategy below the main routing strategy, we can create a simulation of a fixed network even though the layer underneath isn't fixed and the nodes don't correspond 1:1.
However, this means we need to specify virtual waypoints on our virtually fixed network, where the waypoints are connected via the IPv6-like scheme but labelled by means of a unique, fixed designation the ad-hoc layer can use to find where to send stuff.
This assumes that your next hop wants to have a particular property, that of being able to send on to another stage that has the next designated property, and that exactly where it goes is unimportant. So it's now more of a fuzzy hierarchy. One or two bytes won't do for this. I'd suggest a routing label, of two bytes, per hop, to describe the virtual properties that the physical must possess.
There are 8 bytes in the IPv6 routing information, which we're now doubling to get 16. Not convinced that's really good enough, remember this has to be universal to be a serious candidate. We need more levels per planet and more levels to get between planets, asteroids, satellites, probes, etc. We don't, however, need the same level of specificity as we're layering this as a software defined network, an X-Bone, on top of other networks that are transparent to the visible levels.
For this, I'd adopt the TUBA approach of variable length, albeit not in the same way. The suffix is fixed length, the prefix is fixed length, the middle is really only there to simplify the re-routing and to sanity-check decisions. If you had zero latency and an infinite routing table, it wouldn't be needed at all.
I'd therefore have routers collapse bits and expand bits of this routing section, such that the next router is always looking at a fixed-sized window at a fixed location in the header (the main problem TUBA had) and the level of uncertainty as to where to send stuff is kept equal or below what it was at the last hop, regardless of who is moving relative to whom.
The last bit, the unique ID, is just that. A unique ID. If carried by a person, it could be used as the user ID for signing onto a satellite network or hotel network, buying a house, etc. It represents the ordered pair of person and place, such that place can be changed at any time and the new ordered pair is still identified by that ID. I'd use a 512-byte UUID.
This triple of (prefix, route, uuid) then can be used universally. For phone systems, mail, email, it simply wouldn't matter.
You'd want a human-readable scheme on top of that, sure, but the computers would simply do a directory lookup for the 512-byte corresponding ID. This means mail sent to an old address would be forwarded to you, you wouldn't need to sign forms for forwarding. It means if an email service closes, the emails will also still reach you.
The address something is sent to wouldn't matter, regardless of medium. It would only be used to find out what uuid was implied and everything else would be taken care of.