I think the underlying DB error that caused the HTTP 502 has gone away, so yes, there probably isn't too much of a reason to keep this private anymore. I don't think it is very likely that an attacker could intentionally cause DB issues, but if they would, I doubt they would use it just to ensure that they can't get blocked.

In principle, I agree with the decoupling. I have always found it somewhat strange that mw.ustring.upper and mw.ustring.lower are overwritten when the language module is loaded (which authors of module code have practically no control over). However, it might take some thought to figure out how to do this in a non-breaking way, or at least with appropriate warning for downstream users to update their code.

Pages using the Italian pronunciation module are also broken, e.g. https://en.wiktionary.org/wiki/Facci#Italian. Fixing all the individual modules is not the solution here, reverting the breaking change is.

In T403113#11126632, @cscott wrote:

Again, please list the pages with incorrect output so we can fix them. You're making pretty sweeping claims about broken pages.

No, it definitely has not been fixed. There are bound to be more modules that relied on the old behavior. This change in behavior is also entirely undocumented, and even if it were to be documented, it is still counter-intuitive to anyone who has worked on text processing in other languages.

As I already proposed, the fix should be to revert the original commit and then discuss how to proceed forward. I'm frankly puzzled that it is considered acceptable to make a breaking change of this sort and not an immediate priority to revert it when it is apparent that it causes significant breakage. I have made such breaking changes during my career and had to rather quickly come to terms with the fact that I had to revert them.

I'm sorry, but I do not agree that these are "specialist cases". Text processing is a rather common goal, and Scribunto has a variety of functions specifically to support this goal.

In T403113#11126594, @cscott wrote:

Language::uc() and friends are primarily meant for manipulating wikitext and titles, and NFC output in those cases seems appropriate.

Scribunto is not necessarily specifically designed for manipulating wikitext, but for generating it. There are many reasons why internal string processing would want to rely on non-normalized Unicode text.

In T403113#11126392, @cscott wrote:

Wikitext content is supposed to always be in NFC form.

In my opinion, adding a special case for long s to lowercase s is worth it even in spite of the 'technical debt' it would incur, because claſs (which is all in lowercase) redirecting to CLASS instead of class is unacceptably counter-intuitive.

In T364685#9795044, @hgzh wrote:

For now this is intended behavior, see T361934#9692764

I assure you "not been developed after ten years of waiting" is far from the truth.

is it okay to deploy the above config change, i.e. collapse all sections by default, without a MobileFrontend feature to expand sections if there’s only one section?

Well, it is going to have to be in Mobile.js (https://en.wiktionary.org/wiki/MediaWiki:Mobile.js) to run automatically on the mobile frontend in order to get the desired behavior.

In T376446#10203930, @Jdlrobson wrote:

Please note I would highly recommend you don't attempt to override this behaviour with CSS or JS as the code here is pretty complex and it will be difficult to do that without impacting performance or risking future bugs when this code changes. Please do reach out for input/support if you do consider such a gadget.

In T165935#7268637, @jberkel wrote:

If Lua on MediaWiki can't be upgraded to 5.2 or later (T178146 is stalled, with "re-evaluation in 2024"), maybe just the GC changes could be backported to 5.1, to have at least some predictable GC behaviour?

There are plenty of signs that the GC is unpredictable and that this is making this issue practically impossible to solve on en.wikt's side without dropping Lua modules altogether.

Just to note, the inline-block or inline-table 'hacks' do not work anymore, so the only way to actually solve this is to solve the core issue of <table>s causing paragraphs to be split up unless there is an outer <div> present (the resulting HTML looks as in T210695#4846093).