I understand, it isn't perfect, but we do already have the requirement that our (hostname-based) node names be unique for EJB, management, clustering, etc. to function correctly. When more than one server is started up on the same host via domain management, the node name is based on the host name plus the server name (which is unique within a server group, which is a very manageable namespace as it is centrally defined).
Basically if we start up two servers with the same node name, there are a whole host of services that won't function correctly if the user makes the servers interact. It's still a lesser burden to choose a name which can mostly be defaulted to the node name which already must be unique than to choose an integer. Otherwise we're back to the drawing board to come up with a scheme which can use either a full name or topology information (or some other scheme, like topology + full name hash) to fill in the knowledge gap that each node needs for recovery. Using a plain int simply is not an option.
As for the non-roman alphabet-based names, they encode back to the same character set as any other domain name, so we don't really need any special handling for this case as we can perform the same encoding. It would be noted however that such names would have a significantly reduced maximum length, potentially as few as 2 or 3 characters.