I don't see why anyone would want to encode information about the country in the first 64 bits, especially since you can use compound callsigns such as PA/EA4GPZ if you're operating abroad.
Perhaps it would be interesting to have the information about the Maidenhead locator or GPS coordinates of a subnet (where this makes sense). Someone could use this info to make a geographical map of the network. However, I think that this info should belong to an external database (whois maybe) and not be encoded in the IPv6's.
I also don't think it should be done that way, especially because we seem to agree on the idea that we do not want to have a large IPv6 network for amprnet (which we could subnet in creative ways), but rather use the IPv6 addresses provided by a local ISP. We don't have control over the numbering and network size of those addresses, and especially during the initial phase of the rollout there will always be ISPs that do not understand IPv6 and give a customer only a single /64 or even less. Hopefully that will change later, but we cannot wait for that forever.
So, keep all special handling in the last 64 bits and treat the first 64 as random.
I think a special handling of the address should not even be mandatory, only a good suggestion that may help others to determine the source of traffic easily. It should still be possible to send traffic from addresses not conforming to this methid, at most risking that it will be dropped at an internet-radio gateway when prior arrangements have not been made.
Probably a next step would be to standardize a method to distribute information about valid IPv6 AMPRnet networks (that can be somewhat trusted in access lists).
E.g. use BGP, downloadable textfiles, (ampr-)RIPv6, etc. It may not be possible to standardize a single method due to limitations of used software and hardware, although this probably is less important than with the current gateway list. (where we need to remain compatible with very old software that cannot do IPv6 anyway)
Rob