My only take on naming standards is to keep them simple 
and be very cognizant of their scope with respect to the 
organizations that might be required to use them.  This 
is a problem for any meta-specification: no size fits all.

Most of the time, one can make it fit, but sometimes the 
language or the constraints are such that one has to 
push back and say, no, N/A, nahii, nyet.   Odd things pop up: 
for example, a naming convention that requires all 
acronyms to be expanded.  Seems simple enough and 
desirable until one sees the rule that says an 
acronym is unclassified but the name is classified. 
Local rules prevail, but the organization might be 
required to sign contracts that are in conflict. 
I suspect that is one of the more harrowing problems 
of the orchestration languages, as well. 

It gets worse if one tries to subset the spec 
to make it tighter by removing extensibility options. 
No becomes 'no and the horse you rode in on'.

Then there are the naming conventions that force one 
to carry waaay more meta-info in the name than is 
sensible.

len