I discovered this issue about an hour or so ago, and started the following discussion on Enwiki:

In T306883#8349985, @Certes wrote:

On enwp, and perhaps all wikis, Preferences→Search→Show thumbnails in Special:Search can now be unticked. I don't know whether this prevents transmission of images or simply hides them.

Any updates on resolving this? Pics in search results on Wikipedias at all are clogging up the search, and using hacks to suppress the pics doesn't resolve the issue of the pics burning up my bandwidth.

@Jonteemil I think I get what @Jdlrobson is meaning by their comment: The interface functionality of the Wikimedia sites as a whole is their responsibility, but how gadgets respond to changes in the interface (and updating the gadgets) is the responsibility of the community and the editors maintaining the respective gadget(s). The gadget would need to be updated to accommodate whatever changes have been made to the interface ... and in this case, it seems that something definitely changed with the interface to where it affected the gadget.

Looks like the zooming issues have been fixed!

...And with the reversal of the reversal, the zooming issue is back...

So, since this has been sitting here for a while...

The discussion on the English Wikipedia has been archived: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_199#Search_box_and_default_zoom_messed_up_while_using_desktop_on_mobile

For what it's worth, the zoomed screen and search bar issue referenced above also happens on Firefox on mobile.

In T311795#8114460, @TheDJ wrote:

Seems this too is causing problems: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Search_box_and_default_zoom_messed_up_while_using_desktop_on_mobile

Makes me think that maybe we are better off simply removing the viewport definition again, because mobile browsers don't seem to be made to handle viewport definitions for things NOT mobile, very well.

(This refers to the comment from @Aklapper above. There were portions of the comment I felt needed to be suppressed, so I'm reposting what I felt was relevant.)

In T41395#6308658, @Ahecht wrote:

In T41395#6308522, @Steel1943 wrote:

If I'm reading this correctly, the issue I see with approaching the problem in that manner, specifically via resolution "(b)", is that it would erroneously disable pages when viewing talk page archive subpages.

I think you misunderstood. The intention of (b) would be to disable the link if an article exists that matches the current, not the target, talk page. In that case, the link to from [[Talk:AC/DC/Archive 1]] to [[Talk:AC/DC]] would not be disabled unless there is also an article called [[AC/DC/Archive 1]], and the link from [[Talk:NASA/Archive 1]] to [[Talk:NASA]] would not be disabled unless there is an article called [[NASA/Archive 1]]. However, the link from [[Talk:AC/DC]] to [[Talk:AC]] would be disabled since the article [[AC/DC]] exists.

In T41395#6308500, @Ahecht wrote:

That brings up perhaps the most important use case: the talk page of a mainspace article with a slash in it, such as [[Talk:AC/DC]], [[Talk:n/a]], [[Talk:R/K selection theory]], [[Talk:9/11 Commission Report]], [[Talk:S/PDIF]], etc.

A more general fix would be to automatically disable it for pages in a talk namespace when (a) the corresponding content namespace has subpages disabled and (b) a page with a matching title in the corresponding content namespace exists.

This item has been referenced on the English Wikipedia's "Village Pump (technical)" page: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Way_to_disable_link_to_base_page_and/or_root_page_on_a_subpage?

Pretty sure this is resolved now...

Looks like the software's ability to enforce the title blacklist on enwiki is down again. Are there any updates on completing the fix?