It seems silly to proliferate so many wikis when many of them focus on related issues. It becomes the nightmare of having to visit the web site of every user group every few hours vs having all the new posts sent via email to one address so you save time. The real question to me seems to be how to make the software capable of sharing data across silos. Our hardware is much more robust than 10 years ago, our software has matured and now it is time to do content aggregation. We can (and probably should) use the name with the widest recognition as the root of our tree. Then all the branches can continue to function "as if" they were independent for a time - even though they are part of the same trunk. Over time their quirks will need to be harmonized and fiefdoms consolidated into a coherent whole.
We already use disambiguation pages to distinguish between topics with similar names, go one step further and have a multiple articles page. Some contributors have great insight but terrible writing skills and that is where the skills of an editor are needed. Having to police all the differing opinions of supposedly factual matters is more of a censorship (shudder - who will watch the watchers?) or judicial function. Thank goodness for the page history function.
I've setup and used several wikis inhouse, and currently run MediaWiki on the server. The biggest problem I have is with user fears - fear of creating a new page, fear of doing something someone else "should" be doing, learning curve issues. Currently teams are working on a better GUI experience that will (hopefully) make it much easier for a new user to be able to contribute productive work without having to learn a new programming language. Creating a disambiguation page is a good example of something that should be relatively easy to do the first time rather than spend 3 or 4 hours learning how to do it in the current wiki programming environment.
wikimedia-l@lists.wikimedia.org