In deploying wiki systems for collaboration environments, it seems like there are three independent feature vectors in operation.
Sharepoint is strong in Collaboration concepts, but not other two. Its information model is very simple: The site is a list of lists, where each list can be one of: Documents, contacts, tasks, discussion forums and so on. Each of these have predefined schema (but can be changed). A generic 'list' is also available, in which the columns can be created dynamically - each column being of well known type. The home is created using one or more 'web-parts', and each web-part can show content from a specific item of list, or a row of items (with selected columns) from seleted list. Home page (i.e. the central portion of most web sites) is an item - as some row and col in some list. To help navigation, a quick-start navigation bar is available; and a list can be made to be available in it.
Finally, the views are independent of the underlying model, and control the look and feel, accordning to personalization.
So, in sharepoint, if you want to create a page with aggregated content from different lists etc., it is not straightforward. Perhaps we could use sharepoint SDK to do the same, but the fun of using unix-like simple text processing tools is not available.
In contrast, twiki excels in text processing capability (apart from wiki concepts, which is a primary goal.) This is primarily due to its INCLUDE and SEARCH functionalities, which allow it to be used for tasks, FAQs, and even a book. You can visit a set of topics meeting certain criteria, and use regular expressions matching appropriate patterns to collect information. This collected information can be presented in a table. In addition, its plugins provide more involved mechanisms to do text processing - for e.g. spreadsheet functions etc. Twiki has good mix of Wiki and text processing concepts. (And collaboration features are not very well integrated - normally the end users choose the schema.)
But twiki doesn't provide ready-to-use schema for common things such as tasks, issues, contact lists, discussions etc. But in theory, someone can provide plugins to do the same; indeed some such as action tracker are meant for specific tasks. Neverthless, the UI still lags behind. End users expect nice looking interfaces to things like task management or managing a table. Unfortunate thing for twiki is that there is no clear model that can allow third parties to add edit components which employ nice UI. Other new wikis should provide good capabilities for the same.
Each product can grow to fill all the three concepts. Unfortunately we don't find any talk about sharepoint integrating wiki concepts. It will continue to be popular because of good integration with office and other Microsoft components. But wiki could be a disruptive technology. So far Users have evolved from simple email, to using shares, and now using document stores and simple content management to do information management. But weblogs and wikis are new generation of tools for publishing and managing simple content on web. In my opinion, the need of the day is structured information aggregation, deploying common schemas for things like friends and contacts, books, shops, locations and so on: Information that we use everyday. That is dream of semantic web! Can wikis and weblogs fill this need over the time?
In wiki systems, I almost always use outlining - using lists and sublists which most wikis support. The key difference is that you normally have independent topic for each thread. And these are not necessarily connected (i.e. available from one UI). One approach, for e.g. in twiki, is to use 'Idea' or some such word in topic name, and use search to collect and display all such topics in single page. But it is not quite same as what we want ideally: Have all threads simultaneously available.
Second problem is that wiki systems require you to be online by default. But ideas come primarily while you are offline, and it is easy to take out your pocket PC and put a line or two as notes. You require good synchronization capabilities to make this happen, and with a tool which makes its outlining data available in open format.