To get a rough idea of how broadly this is happening, I grabbed a list of the latest 50 uploads to Commons.

6 of 50 were broken in this way, and the broken ones consistently returned a 200 on commons/test.wikipedia/test2.wikipedia, but a 404 on all of hewiki, cawiki, enwiki, dewiki, itwiki, wikidata, and enwikivoyage.

Methodolgy: first, using the XPath support in Chrome's devtools JS console, extract a list of recent filenames:

$x('//a[@class="galleryfilename galleryfilename-truncate"]').map(x=>x.innerText)

Then I scraped those across a bunch of wikis:

For posterity:

(echo 'test test2 he ca en de it wikidat wvoyen file' | tr ' ' '\t' ; \
for FILE in \
..... \
    ; do ; \
        curl -sLI https://{{test,test2,he,ca,en,de,it}.wikipedia,wikidata,en.wikivoyage}.org/wiki/File:"$(echo ${FILE} | tr ' ' '_')"  \
            | grep '^HTTP/2' | grep -v ' 301' | sed 's!HTTP/2 !!' | tr -d '\r' | tr '\n' '\t' ; \
        echo "$FILE" ; \
done) | sed 's/\t/ | /g; s/^/| /;s/$/ |/'

For one file, https://commons.wikimedia.org/wiki/File:Terrible_scene_at_Manders.jpg, I iterated over every wiki listed in wikipedia.dblist.

The arbcom and wg-en wikis returned 200s, but that was just because they were serving a login page. I omitted them here.

It does look like only the test and test2 wikipedias "know" how to serve these files. Sorted by response code and then by wiki:

https://commons.wikimedia.org/wiki/File:Fioan_Fiedler.jpg is, uh, neatly partitioned along the alphabet in terms of which wikipedias it is accessible from:

Don't know if this is related, but thought I'd mention it. About the same time the issue for this ticket was mentioned on Commons, a preview oddity began on English Wikipedia (nowhere else for me). If I open the edit window on an article, I can type. Clicking on Presiew wipes out the edit and won't show me the preview screen. Not browser specific. I have not been able to duplicate that on Commons or Wikisource.

Could T250767 be related @Tgr ?

Change 598118 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@master] filerepo: use makeGlobalKey() in ForiegnDBViaLBRepo::getSharedCacheKey()

https://gerrit.wikimedia.org/r/598118

In T253405#6159451, @CDanis wrote:

AIUI, @aaron suspects that (newly-added?) WANObjectCache memcache key coalescing support might be at fault here.

Yeah-ish. It was a pre-existing bug exposed by key-coalescing (ref T252564). The ForeignFile code in MW was constructing its own cache keys (as if they were wiki-local) rather than makeGlobalKey().

Change 598118 merged by jenkins-bot:
[mediawiki/core@master] filerepo: use makeGlobalKey() in ForiegnDBViaLBRepo::getSharedCacheKey()

https://gerrit.wikimedia.org/r/598118

Change 598120 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@wmf/1.35.0-wmf.32] filerepo: use makeGlobalKey() in ForiegnDBViaLBRepo::getSharedCacheKey()

https://gerrit.wikimedia.org/r/598120

Change 598122 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@wmf/1.35.0-wmf.31] filerepo: use makeGlobalKey() in ForiegnDBViaLBRepo::getSharedCacheKey()

https://gerrit.wikimedia.org/r/598122

Info: I renamed File:Fioan Fiedler.jpg to File:Fiona Fiedler.jpg (typo fix). And I had noticed before that in :de:Fiona Fiedler a message box appeared on top informing about unflagged changes of a file or template. I did the flagging then – it was the file. By default unflagged changes are not visible to readers in dewiki.

Edit: Same situation with the unflagged file changes for :de:Lucille-Mareen Mayr.

Edit2: Oooh, now after the changes I cannot see the file in :de:Fiona Fiedler anymore!

Change 598122 merged by jenkins-bot:
[mediawiki/core@wmf/1.35.0-wmf.31] filerepo: use makeGlobalKey() in ForiegnDBViaLBRepo::getSharedCacheKey()

https://gerrit.wikimedia.org/r/598122

Change 598120 merged by jenkins-bot:
[mediawiki/core@wmf/1.35.0-wmf.32] filerepo: use makeGlobalKey() in ForiegnDBViaLBRepo::getSharedCacheKey()

https://gerrit.wikimedia.org/r/598120

I have problems with https://commons.wikimedia.org/w/index.php?title=File:Baruch_Spinoza_-_Letter_in_Dutch_of_3_June_1665_-_Brief_van_3_juni_1665.png&redirect=no vs https://nl.wikipedia.org/wiki/Bestand:Baruch_Spinoza_-_Letter_in_Dutch_of_3_June_1665_-_Brief_van_3_juni_1665.png
See https://nl.wikipedia.org/wiki/Overleg:Baruch_Spinoza where it's shown as a red link. I purged the page on nlwiki (using the API Sandbox, which solved the issue for most pages), didn't help.

I have the same issue with the uploaded image: https://commons.wikimedia.org/wiki/File:S._S._Arunagirinathar.jpg. Please see: https://ta.wikipedia.org/s/f7t. Thank you.

The same issue for another of my photos/files I uploaded:
https://commons.wikimedia.org/wiki/File:Blue-Corner-2016-aerial-view-Luka-Peternel.jpg

I have a potential idea why this bug occurs. I was editing the Wikipedia page and I had already typed in the code to include the file name that I was going to upload. I speculate that when I entered a preview mode for the Wikipedia page, the Wikipedia might have somehow allocated the file name (of yet non-existent file). Then, when I actually uploaded the file on Commons, perhaps there was a conflict with the file name between the two environments. This is just a guess. I hope it might help.

Of the 500 most recent uploads at the time I pulled the list, 49/500 were affected:

The usual way of displaying images, with [[File:Filename.jpg|...]], does not work on svwp for this image:
https://commons.wikimedia.org/wiki/File:Tjuvbackarna,_Kalmar,_betesmark_med_fornlämningar.jpg
But it is still available on svwp through this path:
https://upload.wikimedia.org/wikipedia/commons/c/c8/Tjuvbackarna%2C_Kalmar%2C_betesmark_med_fornlämningar.jpg
I don't know if that means anything, but thought i should mention it, in case it gives any further clues.

In T253405#6159575, @gerritbot wrote:

Change 598118 merged by jenkins-bot:
[mediawiki/core@master] filerepo: use makeGlobalKey() in ForiegnDBViaLBRepo::getSharedCacheKey()

https://gerrit.wikimedia.org/r/598118

@aaron It looks like we're still seeing the same issues. Stuff from before yesterday is working again (possibly due to the forced churn of this patch), but new stuff remains broken. I suspect the problem is what LocalRepo::getSharedCacheKey needs to be updated as well.

When Commons purges via LocalRepo::getSharedCacheKey, that should affect what enwiki reads via ForiegnDBViaLBRepo::getSharedCacheKey(), right?

Whilw super fragile before, but it seems that implode( ':', $this->wiki, ...$args ) in ForiegnDBViaLBRepo, would have likely matched the result from wanCache->makeKey( ...$args ); in most cases.

Change 598182 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@master] filerepo: make LocalRepo::getSharedCacheKey() use makeGlobalKey()

https://gerrit.wikimedia.org/r/598182

Change 598185 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@wmf/1.35.0-wmf.32] filerepo: make LocalRepo::getSharedCacheKey() use makeGlobalKey()

https://gerrit.wikimedia.org/r/598185

Change 598186 had a related patch set uploaded (by Krinkle; owner: Aaron Schulz):
[mediawiki/core@wmf/1.35.0-wmf.31] filerepo: make LocalRepo::getSharedCacheKey() use makeGlobalKey()

https://gerrit.wikimedia.org/r/598186

https://commons.wikimedia.org/wiki/File:Christopher_Fiori.jpg is also not showing on wikidata and de:wp

Change 598185 merged by jenkins-bot:
[mediawiki/core@wmf/1.35.0-wmf.32] filerepo: make LocalRepo::getSharedCacheKey() use makeGlobalKey()

https://gerrit.wikimedia.org/r/598185

Change 598186 merged by jenkins-bot:
[mediawiki/core@wmf/1.35.0-wmf.31] filerepo: make LocalRepo::getSharedCacheKey() use makeGlobalKey()

https://gerrit.wikimedia.org/r/598186

Change 598182 merged by jenkins-bot:
[mediawiki/core@master] filerepo: make LocalRepo::getSharedCacheKey() use makeGlobalKey()

https://gerrit.wikimedia.org/r/598182

Change 598190 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@master] filerepo: bump LocalFile::VERSION following 88e17d3f7c78

https://gerrit.wikimedia.org/r/598190

Change 598191 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@wmf/1.35.0-wmf.32] filerepo: bump LocalFile::VERSION following 88e17d3f7c78

https://gerrit.wikimedia.org/r/598191

Change 598193 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@wmf/1.35.0-wmf.31] filerepo: bump LocalFile::VERSION following 88e17d3f7c78

https://gerrit.wikimedia.org/r/598193

Change 598191 merged by jenkins-bot:
[mediawiki/core@wmf/1.35.0-wmf.32] filerepo: bump LocalFile::VERSION following 88e17d3f7c78

https://gerrit.wikimedia.org/r/598191

Change 598193 merged by jenkins-bot:
[mediawiki/core@wmf/1.35.0-wmf.31] filerepo: bump LocalFile::VERSION following 88e17d3f7c78

https://gerrit.wikimedia.org/r/598193

Change 598190 merged by jenkins-bot:
[mediawiki/core@master] filerepo: bump LocalFile::VERSION following 88e17d3f7c78

https://gerrit.wikimedia.org/r/598190

Perhaps there still is a problem per https://phabricator.wikimedia.org/T253952 ? An image not showing up.

That is not this bug.