I believe the issue is with lines 337-339 of modules/jquery.wikiEditor.dialogs.config.js. It appears to set the button that an Enter press invokes while the "Insert link" button is still disabled.

It appears the sandbox has been converted back to a regular wikitext page since this issue was posted. https://test.wikipedia.org/wiki/Talk:Pywikibot_test is the designated Flow test page on that wiki for PWB. You could try testing there.

There is no longer an error when passing a falsy (e.g. blank) icon field. It does currently pass the label as the link text, but that text isn't displayed. The icon (when present) is a background image, so it's not a straight replacement.

Is it still worth it to rename the jQuery UI-based classes, or should this just be handled by porting the toolbar to OOUI?

Appears to have been fixed in 6384498d as part of the OOUI conversion of the link insertion dialog.

I've always thought the beauty of FOSS was that any (working and non-buggy) patch could be added as long as there was someone to write it, someone to review it, someone to maintain it, and the possibility that someone could benefit from its inclusion, regardless of what the project managers saw its "value" to be. I guess we could always reopen one of them if someone ever gets around to posting a patch for review.

I'll admit that I'm not an expert on bug management policy, but I've seen tasks (both bugs and enhancements) that are over a decade old, just sitting there completely forgotten, and I've even tried to fix a couple. The priorities of this and its subtasks are way off (they should probably be Lowest), but what exactly is the harm in leaving these open? Unless there's a plan to remove the existing Flow code from Pywikibot too (which would be a personal shame and a disappointment for anyone on Flow-enabled wikis who uses Pywikibot on talk pages), some of the features with tasks didn't end up being implemented in Flow, or the Pywikibot maintainers specifically say they don't want these to be implemented, I see no harm leaving these tasks open for someone to work on in the future.

Reopening as T290818 reverted e76eba6b9619185cceb094c493aed2207d9d7ad1, which had resolved this issue.

e76eba6b9619185cceb094c493aed2207d9d7ad1 was a fix for T38227. If you revert that commit with the above patch, please either reopen that task or mark it as invalid.

It seems like the only thing to fix here is decoding external link URLs that have been pasted in. The functionality to parse standard page links already exists, and query string-style links are covered under T33500.