My original idea was for a rather strict character set but this is something that needs to be discussed thoroughly.
You should interpret my post in a way that still makes sense if you actually disallow periods in the name. That is, I was making a general argument about the role of TLDs and how "avoiding collisions" using TLDs is an artifact and not what would happen naturally if you remove the effect of the laws that are entangled with the current system.
Yes. But my original reply was not so concerned with the "legalities" of .org vs. .com etc., but moreso that it allowed for a sort of self-sorting and the multiplication of the namespace across however many TLD's there were. (Which, recall, back in the beginning there were only a few; .com, .net, .gov, .edu, .org, .mil, and .arpa.) And that there could be multiple entities which would reasonably desire a given domain name, not only for "squatting" purposes.
Let's put it this way: DomainShares-the-namespace needs a name. No matter what, there is one DomainShares-the-namespace, no matter how you slice it.
Bonus challenge: Make it under 4 characters.
Ok, I again suggest:
.nm
.key
I think .nm is pretty recognizable as the root characters of name/nomen/nombre/etc. which means "name" to most Western languages, even non-Romance languages such as German and Russian. I guess it is a problem in that it is also the abbreviation for a US state (New Mexico) and there already exists the 2nd-level domain .nm.us, which is used by official government entities in New Mexico. I could see some potential for confusion there. Perhaps .nom as an alternative?
I also think .key is pretty good, as a tie-in to Keyhotee and the idea that this system is maintained by way of public/private cryptographic keys. It also has good mental images: a key unlocks a door, etc. However, it is probably not as internationally oriented as .nm.
EDIT: I will also say, if the topic is "discussed thoroughly" then you might well end up with a design-by-committee, which doesn't work very well. I would say, either start with the existing DNS rules and relax them somewhat; or allow all of UTF-8, and then restrict it somewhat. Going a middle route of picking and choosing, and allowing this but not allowing that, is going to lead to nothing but confusion. Think through all the options, but go with your gut, and don't allow it to get more complicated than you can handle. Internationalization is notoriously difficult to work on.