Now completed.
There is such a proposal, see [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org. This is the place where consensus for mediawiki.org changes is checked, hence I'm opening the discussion here.
Also, some users have already started disabling LiquidThreads on some talk pages to use wikitext instead: what to do? Should that be done on more or less pages?
LiquidThreads was an unmitigated disaster, in my view, and has made the site worse for being here. History before it was enabled was lost (or, at least, very hard to find) the links in e-mails never take you to the thread they're supposed to, the UI is horrible and it is difficult to find things you are looking for. It actually makes the site harder to use for anyone at all experienced in wikis, not easier, and so should never have been enabled.
I haven't used Flow, so I don't know how it compares, but I would certainly vote for removing LiquidThreads! If Flow actually works in a wiki-like way (i.e. you can view history, see the state of the page before it was enabled, edit comments where necessary, etc.) then I might be persuaded that it is a good replacement, but given our experience with LiquidThreads I am fairly sceptical. For it to work it would have to be something that works inside existing wiki pages, rather than fighting against them. It would also be a requirement that all LT content can be 'migrated' to Flow so that it is not lost or broken. It is not acceptable for it to simply be shunted off to an 'old threads' namespace and abandoned - it needs to appear where it was originally posted.
The issue is as much about how the extension works behind-the-scenes and how well it integrates with the rest of the wiki, as about the interface it provides.
For example, I don't want to lose my current talk page, nor its history. If what is there can be converted seamlessly to Flow, without losing my ability to view old revisions of the page (pre-flow and post-flow), archive things in the way I have done in the past, include some non-thread-like content (e.g. introduction section) and link to specific items without the links breaking as items change (e.g. if they move to 'page 2' of the listings) then it might be viable. Otherwise, please just remove LiquidThreads and don't mess up the wiki with further incompatible plugins.
PS - From reading the wikitech-l post, it looks like once again this is a decision being forced upon us without any kind of local consensus. MediaWiki.org should not be treated as a test site, without community buy-in. If you want people to be antagonistic towards Flow, and to resent its presence on the wiki, then that is a pretty good way of going about it.
Also, I didn't realise quite how experimental/incomplete Flow currently is. Therefore, my vote is (for now at least) a firm no!
The comment from Risker/Anne sums things up pretty well, as far as I'm concerned.
Please just remove LiquidThreads and come back to us with a proposal for Flow when it is out of beta and feature-complete.
Please no back to plain wikitext talk pages, at least for talk pages with hundreds of posts (like Current_issues and Support_desk). Wikitext talk pages are terrible to follow and archiving is as bad as the wikitext discussion format itself. I prefer LQT (in it's fairly bad state) before wikitext, but i welcome a move to Flow, after it is in a workable state (see, e.g., this mail).
So, from my side: 
Support
Is it possible to have a complete list of LQT pages on this wiki? That would help the discussion.
Certainly it makes sense to use modern discussion software on Project:Support desk, as that is a high-traffic forum-style page which is aimed at IT professionals and server administrators more than wiki users.
I agree that for the support desk, and maybe a couple of other support-related pages, a more forum-like approach is sensible.
However, one does have to question why we use the wiki for these purposes at all. We don't use the wiki for internal issue tracking, so I'm not sure why we are using it for support. I am not aware of any other company or open source project that would consider using a wiki for handling support issues - it is clearly the wrong tool for the job.
Perhaps a more sensible solution would be to use support desk software for handling the support desk, rather than trying to shoe-horn non-wiki-like tools into the wiki, which will inevitably bring unsatisfactory results (as has been shown with LQT).
Special:PagesWithProp also works. - currently LQT is on 1,639 pages - (I'm not sure why that number differs (1,567) from the search that Nemo linked?)
Re: existing posts - currently 52,526 individual posts. Of those: 24,897 of those are in Project:Support_desk; 1,269 in VisualEditor/Feedback.
I'm asking devs for help getting a more detailed listing of All pages ordered by size (number of posts).
[Update: A list of all pages with more than 10 posts, is now at phab:P417, and converted into an onwiki page with links at Flow/LQT pages.]
The Flow/LQT_pages are interesting, thanks. Just for fun I looked at the even (non-talk) namespace numbers: One entry in 90 might be odd (3 contributions counted as 12), and for the Project:Forum redirect I didn't get why it's counted as 94.
I wonder why LiquidThreads Test Page isn't listed. I was about to say to not convert that page to Flow, but it doesn't appear on the list.
Was it skipped on purpose, or there's a problem with the query used to gather this information? A description of what conditions were used in the query, or post the query itself would help.
@Be..anyone: Thanks. I noticed the oddity of namespace 90 (Thread) even being included, because I had to manually turn the plaintext list into a wikitable (hence my update to Project:Namespaces). But I didn't notice the disparate numbers; I'll ask. I'll also ask the devs about the redirect.
@Ciencia Al Poder: The LiquidThreads Test Page is on the list! 283 posts. (I didn't cleanup the underscores (now done) which might have caused a ctrl-F to not find it). :) But I'll ask the dev who ran the query, if he could provide a copy from his scrollback.
Whoops! How did I missed the underscore thing? Meh, maybe because I have all links underlined by default, which makes the underscore virtually indistinguishable from a space. Sorry
So far, after HappyDog has questioned the existence of Project:Support Desk, I didn't see a single person defending it. It looks like we're ready to wrap it up?
Once the page is converted to Flow, AFAIK we can just fully protect it (the board) and add two big buttons to the header, linking existing support venues (i.e. StackExchange and mediawiki-l).
Well, I'd defend it, but I'm not sure how to bring that in a task that aims to "Install Q&A system at ask.wikimedia.org". I'm still expectant to see what would be the resolution. What I'd say for now is that I don't have an account in stackexchange and I don't plan to help there.
Surely making a decision is dependent on the resolution of phab:T31923? No point doing any of that (freezing, redirecting, etc.) until a decision has been made about what those support venues are? Doesn't really affect me as I neither use nor curate it, but it feels a bit like you're putting the cart before the horse.
Well, as far as I can understand, having the support desk converted would break the currently expected workflows (e.g. the moves described in its header?). The path of least resistance seems to be the consolidation of existing venues rather than the creation of a on-wiki support desk with a new discussion system.
Note: We'll be holding an IRC office hour for Flow, this Monday at 19:30 UTC / 12:30 PDT. You can find information on how to get online, including a link to a webchat option if you don't have an IRC client, on the meta office hours page. The intended focus is for questions about the LQT -> Flow conversion here. Everyone is welcome for discussions and question answering. Logs will be posted on the meta office hour page afterwards. Thanks.
Few minutes of testing were enough to discover that
WMF, please ensure you table such proposals only after you've thoroughly tested the conversion. Thanks.
I don't know if it's just an unfortunate coincidence, or what, but since this announcement, the usability of LQT has degraded a lot...
First I reported that submitting a reply doesn't display the reply unless you refresh the page (task T93374).
Today hitting "show preview" displays a confirmation dialog about leaving the page, and if you proceed, you end up submitting an edit to the underlying page and not on the message you was editing!
PD: Reported as task T94089