Once added to a project or to the server instance as a whole, languages cannot be removed. This is inconvenient if you've added the wrong locale, etc.
I would say it was implemented this way as removing a language that is currently in use would be difficult. But, in most cases, deleting a language would be required directly after it was entered incorrectly. In the future, we are looking at making all known languages available to the instance by default and you would only need to enter custom languages. So in that case, deleting custom languages would be a requirement and other languages should just be disabled. I'd say we should probably make this interface similar to the new project/version language settings where disabled and active languages are 2 separate lists and mass activating/disabling in bulk is much easier. Would the above solution solve your instance language configuration problems?
We are certainly not looking for the requirement of removing a language that is in use -- this would be to clean up if it was entered incorrectly, as you say. I'd agree that the global languages interface should be similar the project languages interface -- which does have the ability disable languages. If your plan gives us that ability, as well as mass activation/disabling that sounds like a win.
Migrated; check JIRA for bug status: http://zanata.atlassian.net/browse/ZNTA-54