I have wondered what the name of the Spatial class is good for and searched the code. I have found two things. First for logging purposes. Second for the two methods "detachChildNamed(String)" and "getChild(String)". These methods are not used internaly except from the "GameStateNode" for intruducing methods such "activeateChildNamed(String)". We get better logging (names insted of reference ids) and two methods that are not internaly used. But at what cost? EVERY Spatial in the scenegraph (which may be huge for big projects) have some bytes for the reference of the name, generates a String object which itself costs even more space. And therefore the garbage collector will switch in more often.
My question: are the advantages bigger than the disadvantages? My personal feeling is no. What do you mean?
Leave the gamestate system out of this 
The GameState’s names are not related with Spatials, and as you won’t ever have thousands of gamestates, you’ll gain nothing removing that functionality.
Oh yes, my fault. So there is realy NO internal need of the spatials name. Only logging and the two named functions for ease of use. Again: are that features worth the cost of mermory and performance?
In ogre3d, they use names but require created spatials to be made with a factory method. This way, they ensure every spatial has a unique name. I think jME names are there because Eberly used them. Why he used them I’m not too sure. Maybe just to make things easier on the human side?
I’ve been working heavily on an implementation of jsr184 (aka Mobile 3d) and that api uses int userids for tunneling down a scenegraph in search of a particular Node, Mesh, etc. Our name String is useful for the same purpose, although I kinda prefer the int approach for memory sake.
Yes, for such an purpose the names MAY be usefull, but only if you can ensure that they are unique, what you can not with the current implementation. And its the question if there are more memory efficient methods to resolve such problems, because all applications that do not require this feature must also live with less memory. In this particular case I whould think of a hash with id/reference pairs or such alike.
uniqueness does not necessarily matter. Typically in the mobile 3d stuff, everything has an id of 0 except that one SkinnedMesh or important bone node for swapping weapons, etc. You set that up when you export the model.
Anyhow, I see your point, sure… If you use the same name everywhere though, I think the compiler should point all the instances to the same place, leaving you with just the overhaul of the reference… shrug
Ok, nice. But the original question remains: should the name be removed? What say the other developers? Or is the question absurd?