The easiest solution in my view is to let mos: become a normal interwiki prefix like all others. Yes, this breaks a couple thousand links on the English Wikipedia. Most of them (those not in old edit summaries) can be fixed by a few bot runs. For the people who type in shortcuts or follow links from old edit summaries, just temporarily (for a year or two) turn the target pages on the new Moore Wikipedia into soft redirects with information that this is a deprecated shortcut.

I think the original bug was fixed soon after it was reported. I still use Monobook (and the responsive/small screen version on my phone) and this problem has gone away. I think crosswiki notifications are still broken in responsive Monobook, but that's a different issue.

The change to "Delete this page" and "Move this page" in Monobook is just annoying. What page could I possibly be interested in interacting with if not "this page", which is now displayed three times, taking up valuable screen estate. Monobook needs short labels to work well.

The problem of wrong category member counts comes up time and again (currently on enwiki at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Problems_with_speedy_deletion_category_counts ). It would be really helpful to have some workarounds for the next time. If there are performance issues, just restrict the "force recount" action to admins or similar.

Actually, the display of the notifications after you click the button is also broken. I see them for a second, then they disappear and I just see a large white frame.

The difference between the first and the last pictures is the bullet points, which are new. Whatever was changed has made it very difficult to click the "tools" button that is behind the notification icons (the bullets make it very easy to click the notifications instead of the button behind them). This makes it much harder for me to access my watchlist on my phone (Chrome, Desktop Wikipedia, responsive monobook, which is usually the most comfortable for me).

I second the suggestion to check for what vision impaired users do: if, say, a quarter of all vision impaired users use larger thumbnail sizes, then although that is not a large percentage of all users, changing this would have a large impact on a specific group. In this case, should this option be removed, it would need to be replaced by a functionally equivalent accessibility enhancement. Accessibility is a core feature, not something of "little benefit".

If there are several links (via redirects) to the same disambiguation page on one page, some of them do not have the mw-disambig class added. See https://en.wikipedia.org/wiki/Morris_(surname) : the "Pat Morris (disambiguation)" and "Patrick Morris (disambiguation)" are both redirects to the same disambiguation page, and only one of them has the class.
Discussed at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#"Show_disambiguation_pages_in_orange"_gadget_failure?

The English Wikipedia community already correctly tags all non-free media with [[Category:All non-free media]]. If PageImages chooses not to use this (machine readable) system but relies on a different one (whose documentation I was unable to find anywhere on the English Wikipedia), that does not seem to be the English Wikipedia's problem, but one with PageImages.

The view that the English Wikipedia is "extremely puritan" is a question of what you compare it to. Other comparable major encyclopaedia websites, for example the German Wikipedia or the French Wikipedia, manage without having non-free images at all.

In T124225#1970425, @Deskana wrote:

In T124225#1970338, @Ruud_Koot wrote:

I'm not exactly sure to which aspect of the app you're referring, but I would dispute that. Whenever you take a non-free image out of it's immediate textual context its non-free media rationale no longer applies.

I disagree, as I don't think the images are taken out of their textual context. As I also said above, the situation is not black and white, the fact that there is room for debate about this is exactly my point.

In the Android app's Search dialog, non-free images appear without a textual context. As for the link preview, how do you detect whether the snippet provides critical commentary per the NFCC?

In T124225#1964289, @Dbrant wrote:

To add a bit more product perspective, I would also disagree with this kind of change, since it would translate into a suboptimal experience for our users. I will 1 @MaxSem's comment that it should be up to the client to show or hide the image. I would rather exert a little more effort on attributing the image on the client side (whether via metadata, watermark, etc.) in accordance with legal requirements, than constrain PageImages unnecessarily.

In T124225#1963168, @Anomie wrote:

There's probably no legal requirement here, as it's probably ok under Fair Use. But that's not the point, the point is that the wikis' exemption doctrine policies (possibly including the licensing resolution itself) are stricter than Fair Use and don't permit non-free images for decoration of lists or "navigation". If this or something like it isn't done, you'll have continuing fights with vocal people on enwiki over the various features you're developing that do this.

If the attribution for images used via PageImages is not improved, you will also have fights with vocal people on other wikis. The German Wikipedia currently disallows linking a non-PD image to anything but its image description page, see https://de.wikipedia.org/wiki/Hilfe:Bilder#Von_der_Dateibeschreibungsseite_abweichendes_Linkziel