Thanks for filing! Somehow there wasn't a stewardship request until now (possibly because technically the extension does have a steward), but there have been plenty of discussions in various places. The most salient points IMO:

• Flow is a victim of having a grandiose vision out of proportion with WMF capacity at the time, resulting in many unnecessary and costly layers of abstraction. It was supposed to be a workflow engine able to provide different kinds of talk page segments, to support various worflows like normal discussion, voting, deletion discussions etc; but the only thing actually implemented is threaded discussion. Because the original vision didn't fit well into MediaWiki's core concepts, Flow tried to reimplement many things (most notably the revision system, as Flow was imagined as a somewhat wiki-independent system able to support discussions which simultaneously appear in multiple wikis, while MediaWiki does not have a concept of a page being shared between multiple wikis), resulting in a lot of code complexity and in unintuitive behavior around various pieces of functionality that you would expect to just work without an extension having to work hard for it, but in the case of Flow either don't work or need to be kludged around. E.g. custom code is required to inject Flow edits into Special:RecentChanges; CirrusSearch does not index Flow content at all.
• Besides lacking or unfinished integrations for various functionality, there are also quite a few things that are just broken, mainly around configuration management (e.g. enabling/disabling Flow for a specific page).
• The maintenance cost of Flow is low for now: the few wikis which use it have gotten used to its shortcomings so while new bug reports do get filed every once in a while, there is rarely an urgent reason to work on it. That is only because there haven't been any core architectural changes crossing its layers of abstraction, though; given its dependence on Parsoid, it might cause significant overhead work for parser unification. And any major change for patrolling would have to deal with all the patrolling-related feature reimplementations in Flow.
• Also, anything that involves posting a message to a some page needs to have a separate default and Flow implementation. On the frontend side this is somewhat managed via mw.messagePoster, on the server side there isn't an off-the-shelf way to do it.

So, from an engineering perspective there are very good reasons to sunset it, IMO.

From a product perspective, deployment of Flow to new projects was put on hold because of the talk page consultation, which was launched in answer to various community objections to Flow. That consultation eventually charted a completely different course, DiscussionTools, which is now enabled on all wikis although not all features have been fully rolled out yet (but AIUI it's close to happening). DiscussionTools implements the most important Flow features (a modern commenting interface, the ability to subscribe to specific threads, permalinks) in a manner that's much less disruptive than Flow (you can opt to use normal wikitext editing instead and you won't see any change at all); it lacks some other Flow features (as it's a fake thread system on top of wikitext, it does not include e.g. archiving and moderation features); it doesn't suffer from Flow's unfinishedness (e.g. lacking search integration, various warts around patrolling/antiabuse features).

So, the obvious thing would be to try to see if the wikis which have enabled Flow are sufficiently happy with Flow replace it with DiscussionTools, and then convert Flow conversations to wikitext conversations. This is probably a big chunk of work (do a consultation, update and test the import script, archive content just in case etc).

(cc @kostajh who thought a lot about this)

See also T187487: LiquidThreads: code stewardship review.

See also T123522: Implement a server-side mw.MessagePoster equivalent.

I feel that T324416: Red links malformed: the query string is appended twice is a pretty major issue to have in software that is deployed to production.

One important feature Flow provided is a infinite flow of discussion - i.e. a discussion page that never needing archiving. Many wikis runs archiving bots, but bots need human maintanence and is not enabled by default, which means the talk pages of inactive users may become longer and longer. Also, a system to browse index of threads by date may be useful (this is currently not provided by Flow, and some bots regularly maintain pages like https://commons.wikimedia.org/wiki/Commons:Village_pump/topic_list). If we support infinite discussion flow, the archive system may become obsolete.

An infinite discussion system may also be useful for such "bot report pages" such as this one (this page pre-dates Flow and the bot is no longer active).

(updated 2023-02-11) What we need to do if we need to remove Flow: Identify features Flow/LiquidThreads have (or would have) such as above one, and find the replacements.

Another issue worth mention in traditional discussion page is if you want to redact something in discussion there may be thousands of versions affected (T276514: Feature idea: Selective content deletion for revisions). Such issue does not exist in Flow.

Harping the virtues of Flow won't change the fact that the communities clearly prefer DiscussionTools as the Talk Page consultation shows.

In T325222#8974034, @Pppery wrote:

Harping the virtues of Flow won't change the fact that the communities clearly prefer DiscussionTools as the Talk Page consultation shows.

So what is better is T321716: MediaWiki discussions on individual pages.

This task is about code stewardship of Flow. It is not about achieving feature parity between Flow and DiscussionTools. Thanks!

I was curious how easy or hard it would be to sunset Flow. Looks like it's installed on 48 wikis: https://noc.wikimedia.org/conf/highlight.php?file=dblists/flow.dblist, so not particularly easy.

I ran across the bug T324416: Red links malformed: the query string is appended twice on mediawikiwiki earlier today which is what got me digging. I agree that's not a great bug to have in production.

I just read a bunch of old Flow tickets, and apparently a huge downside of this extension is that it becomes uninstallable once it starts being used, due to Flow data being put in certain non-Flow SQL tables (for example, logging). Uninstalling it without having a bulletproof cleanup script (T188806: create a Flow uninstall script) risks fatal errors long after the extension is uninstalled, when users click certain log links and when admins try to undelete certain pages.

It sounds like a previous WMF team explored uninstall options, and decided that an uninstall script was a risky and expensive option, because of how much production SQL database modifying they'd have to do. Probably wisely, they opted for the "hide every thread then flip a config variable that prevents any new Flow stuff from being created" option, giving them a "de facto" uninstall option that wasn't so risky.

Do we have an official moratorium on installing this extension on new wikis? Should we consider one? I think new installations would create a lot of technical debt if they ever needed to be uninstalled.

In T325222#9034146, @Novem_Linguae wrote:

Do we have an official moratorium on installing this extension on new wikis? Should we consider one? I think new installations would create a lot of technical debt if they ever needed to be uninstalled.

https://meta.wikimedia.org/wiki/Limits_to_configuration_changes#forbidden-extensions

In T325222#9034057, @Novem_Linguae wrote:

I was curious how easy or hard it would be to sunset Flow.

See the dedicated task at T332022: [Epic] Undeploying StructuredDiscussions (Flow).

«So, the obvious thing would be to try to see if the wikis which have enabled Flow are sufficiently happy with Flow replace it with DiscussionTools, and then convert Flow conversations to wikitext conversations»
Flow is one of the tools used to successfully limit harrassement on the wikis and I am really surprized to know that there is a serious move to dismatle it.
I welcome many newbies on the francophone projects and I think this tool is badly needed and has proved to be very successful for newbies,