I don't know about other fora, but en.Wikipedia _requires_ use of Wikiformat in talk comments, even if a WYSIWYG editor is normally used, so we can discuss which modifications of the format will display properly. This may not apply to user talk pages (although I've found it helpful, at times, to show users on their own talk pages what their edits might look like), but it does apply to article talk pages, and definitely to template talk pages.
Any ideas as to implementation?
Templates are frequently used in discussions indeed, and images also, for example when discussing whether such or such image is appropriate for the article.
Thinking about it, I don't exactly mean "Wikiformat". I mean exactly the same format as used in Wikipedia articles, whether in a WYSIWYG editor (now beta or possibly gamma on en.Wikipedia) or in raw Wikiformat.
Arthur & Cenarium: Check out the 4th item at Flow Portal/Use cases#Talk namespace, and see the example-edit link. The thread that example-edit is in, en:Talk:GlaxoSmithKline#Sidebar, is a discussion of template content & design!
I agree that the current-documentation isn't describing things perfectly (and the confusing discussions so far on en.wiki made it worse), but the devs definitely understand that this particular workflow is prominent/frequent/important.
There's a lot of brainstorming in the docs, and a lot of the docs contents haven't been updated in months (or were written by non-developers who were helping to brainstorm/document), so the exact wording is often... inexact... If that makes sense. :)
Yet I'm under the impression from the "Avatars" thread and others (see Thread:Talk:Flow/Avatars/reply (23)) that templates wouldn't be parsed, at least as planed (even though old LQT can), and that if we want some particular template-like functionality within threads, we'd need to make a specific feature request. It's just impossible, considering the time it takes for bugs to be addressed, and the constant need to tweak, deprecate and renew those templates on short notice. Not including demonstrations, on en.wp there are literally thousands of templates in active use on talk pages in-threads (tens of thousands if we include templates that are little used or deprecated), so even the possibility of putting templates in the header of threads would not work. Just to give a few examples: the series: edit protected, w:Template:EP, ESP, UAA, AIV, RFPP, w:Category:Image with comment templates (291 there), w:Template:User and numerous variants (136 at least, see w:Category:Username internal link templates), plenty of linking templates as well (w:template:bug for an ironic one) and the multitude of citation templates (thousands, often used in comments), of course the thousands of user message templates - see w:Category:User namespace templates and subcategories (warnings, blocking, welcoming, awards, etc), various hiding templates to hide some of the message(s), miscellaneous formatting, workaround and shortcut templates, etc. And it's just thinking about it for a few minutes, the search on wp is down again so I can't refresh my memory.
Not supporting template transclusion is definitely a blocker that even in user talk namespace would fatally disrupt critical user interaction processes, scripts and bots, and the need for flexibility and reactivity excludes a 'just ask over at bugzilla' strategy, which wouldn't work for the varied inline/linking templates anyway. It would monumentally increase the workload for experienced users, mechanically many of them would reduce their involvement, and consequently, it would very badly affect inexperienced users since experienced users would have less time for being helpful to them. It's without a doubt something the community could not accept at any time for any duration (that is, even with the assurance that transclusion might potentially be eventually tentatively supported in some unspecified projected future release). And when I'm talking about the community, I don't mean just the en.wp community, but the whole wikimedia community. Other wikipedias and other projects intensively use templates in-threads as well (to the extent that this has led to 'wars' on commons and meta between competing discussion templates...).
For the sake of clarity, since this has confused some commentators, the template support mentioned at Flow Portal/Use cases is only for the 'metadata' of the thread, i.e. what I called the header of the thread. There is no support for in-threads templates, that is within comments, which is why the example of the unblock template is given as something that would have to be requested as a special feature over at bugzilla. Which in real life is totally unworkable.
Not supporting template transclusion won't actually cause as many problems. For example: DPL bot currently subst's a template that amounts to a typed-out message saying that you linked to a dab page.
Okay, we need those messages. But do we really need that message to be "a template"? Don't we think that we could just have DPL bot leave a message for you without technically using "a template" (directly) to get those words onto your talk page? It would require tweaking the bots, but this seems totally achievable to me.
The unblock template is perhaps more complicated, since it adds a category and some instructions rather than just a message. But I still think that it might be feasible to find a non-template solution for this. For example, what if all block messages had both a "Reply" and a "Request unblock" button, with the latter providing all the support that the template currently does (except without expecting newbies to be able to use a transcluded template properly, since we know that some of them can't)?
I wasn't talking about those templates (many of which should be substituted, and the block template might be redesigned, and would probably need to be redesigned as it needs to add a category to the user talk page, which would end up being added to the thread in any reasonable implementation of threaded comments.) I'm referring to templates which represent what the user may be trying to get into an article.
Basically, any template which might be placed in an article needs to be able to be placed in a comment. Something with scratch spaces might partially solve the problem, but it would significantly reduce usability of Wikipedia.
Some bots and scripts may possibly be adapted (it would have to be technically feasible, and that script/bot developers be sufficiently motivated). But then how could we (wikipedians) edit the message if it's not in an editable page on wikipedia but hidden in some bot or scipt code ? User message templates are changed quite frequently. And then again, users without the appropriate scripts would have to do everything manually. This would represent a significant disenfranchisement of those, which includes all unregistered users (and also many experienced users who don't find it useful to have plenty of scripts and prefer manually adding the templates). They would either have to do their best to write manually those complicated messages or good alternatives (which often require fetching diffs, article titles, dates, external links, etc), or they would add brief messages inferior in terms of editor guidance, or altogether stop notifying users, which according to wikipedia policy is necessary in various occasions. Even if some specific situations could eventually, at some point in the not too distant future, get covered by feature requests at bugzilla, that would never be reactive enough. We would seriously loose an enormous amount of functionality, even in user talk only.
And for the huge number of manually added inline templates, some of them I mentioned above, the only way to adapt would be to reverse to full manual, which would be a monumental increase in workload. Having to write down the wide variety of linking templates (citations, article, user, template links, helper templates at noticeboards, etc) would be excruciating, users would be discouraged. Let's not imagine what would become of AIV without AIV templates, RFPP without the RFPP templates, RFCs without inline links, TfDs without w:template:t1 and co - all of those templates require regular changes which excludes a bugzilla-mediated update process.
We would no longer be able to easily cite references on talk pages, which is crucial for verifiability discussions. So that we can take into perspective the extent of the loss, let me give as example one single citation template (one of the most used): cite web is transcluded almost 10,000 times in main talk namespace and a bit more than 2000 times in user talk namespace, excluding some sandbox pages. This isn't even the most used inline template on main talk pages, and on user talk pages, User has tens of thousands of transclusions.
And then as Arthur Rubin mentions, we could no longer give in-comment examples of templates when discussing them directly, which happens every day in all talk namespaces, just check out w:Help talk:Citation Style 1 or the thousands of transclusions in talk namespace of the template families infobox, navobox and co. And unlike for some talk page messages where the ability to subst: alone may be sufficient, try to subst one those templates, and then well :)
For the bot question, why not have the bot's message reside in an editable page on Wikipedia? The bot's command then only needs to be changed from "subst this template" to "copy and paste this page".
Then that page could simply be a template. The problem is that it's not simply "copy and paste", the relevant information must be retrieved (username, page, revision, edit, external link, date, log, etc), integrated within the template and ultimately converted in plain wikitext. Mediawiki knows how to convert by subst:ing, bots don't naturally. The bot would have to make the correct replacements, it may be possible, only bot operators would know if this can be done properly - I'm not, but I don't think it's trivial. In theory it is at least for subst:able templates by editing on any page where you can subst then retrieve the wikitext then make the edit, but it looks like a unusable hack to me. Maybe you suggest using another language than mediawiki, but this would require substantial community resources to pull together and relatively few users would have the knowledge for editing those pages.
Still, I would expect that subst: at least be usable in comments. Even so, currently many messages transclude templates, and most often those templates can't be subst:ed (at least without leaving a giant wall of wikitext and likely a few errors), it would be unpractical to translate them in another language, so it's out of question for bots to add them on their own. But it's just for bots, real users would still be left adrift in space, with bugzilla far, far away...
Ironically, I think the trend is to get away from the mediawiki language for simplification purposes, but in the same time this results in loss of function: too complicated things can't be done anymore, even though they remain essential. I think the general approach of Visual Editor of having both the simplified interface and the advanced interface, while noting that not everything can be done with the simplified interface but there's always the advanced interface for that purpose, is best. Ideally Flow should follow the same principles : simplifying without incurring loss of essential function, even if there is an additional desired change in appearance. Outsourcing all complex functionality to developers is just impossible, they already have enough on their plate, we need reactivity and specificity, and it's just not the wiki way.
The unblock template should be done as a Flow workflow: