A node-page exists twice. It connects free communication media like blogs and wikis. Whenever a node-page gets changed on one medium it automatically changes on the other as well.
A wiki has a xxx-blog node-page. You see the blog's thread on it as a wiki page, but can not edit it. You can only add comments below. New comments from the blog on the node-page are visible on the wiki just like normal entries.
A blog has a xxx-wiki node-page. You see the wiki page as one single thread there and you can add coments on the end of it. New comments from the wiki on the node-page are visible on the blog just like normal entries.
Same for wiki and wiki. Node-pages would not be tied to threads then.
To make a first step: Alex, a page that exists twice, one on emacs, one on community. Whenever someone changes it, you see both changed. Possible?
Or at least, when something is changed on one of them you see this reflected in the recent changes of the other one.
The first step you propose, "when something is changed on one of them you see this reflected in the recent changes of the other one." is very similar to UnifiedClusters. So I'd say we already have that working.
Sharing threads with blogs is a good idea. I propose we rename this page SharingThreadsAcrossMedia?, since that's more descriptive than "NodePage". I also feel this page should maybe be moved to InterWikiWiki?, or to OneBigSoup wiki.
Of course, since most wikis don't have true threading, it would be a little annoying (not necessarily extremely difficult, just an annoying and somewhat involved hack) to implement the requirement to only add at the end of the shared thread.
The final technical question is, how should the wikis and blogs communicate. First, one could use a remote interface API like Atom for the wiki to post to the blog or vice versa. Alternately, one could develop a different protocol for thread synchronization. Another thing to keep in mind here is the nascent ThreadsML?, a (not yet standardized) format for representing and passing around threads.