Change #1307566 had a related patch set uploaded (by Audiodude; author: Audiodude):

[mediawiki/extensions/MultimediaViewer@master] Add shareable Media Viewer URLs with matching OpenGraph metadata

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

Change #1311421 had a related patch set uploaded (by Audiodude; author: Audiodude):

[mediawiki/extensions/PageImages@master] Let ?pageimage= select the og:image from among the page's images

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

The built-in "Share" functionality in Mediaviewer avoids this issue by linking to the File-description page on Commons instead.

So this is (afaik) specific to link sharing through manual copying of the URL from the address bar, or on mobile when using the native "Share" menu.

I think this approach has a few issues:

• It causes a cache miss on the CDN due to introducing a new URL variant for which the entire article needs to be generated and stored on the CDN. This means users clicking the link will likely have to wait for backend servers to generate it, which may be expensive on the infrastructure when broadly deployed. This URL is non-standard and non-canonical and thus, after being generated, it will go stale and not be purged when the article is edited. This could be mitigated by using a parameter that we strip at the edge. We have precedence for this with wprov.
• It obtains its ParserOutput object from a hook. This risks causing a second parse and ParserCache miss for the whole article during the same request, if it differs from the ParserCache key retreived for the pageview more broadly. This could be mitigated by using a hook that has access to the ParserOutput object rather than retreiving your own.

The intention of the user is somewhat fuzzy:

• The reader has not left the page and should be able to return where they left off when they close Mediaviewer.
• The reader sharing the link likely want to share the photo. Our File-pages aren't very attractive and look visually very different, so it make sense that we show the same Mediaviewer experience to the recipient. Showing something that is visually very different, even it if features the same photo, would be surprising.
• The reader sharing the link may communicate with the recipient and talk about other photos in the same gallery, forward and backward. So preserving the article context is probably desired, because that's a proxy for preserving the gallery context (photo before/after this one). Likewise they may talk about closing the modal and refer to something there and expect to land on the same article.
• The recipient, unrelated to the reader's intentions, probably benefits from having the article context available. Even if the sharer didn't care, the recipient may be interested in reading the article, given it is directly related to the photo.
• The URL is clearly about the article. The rest of the metadata will also be for the article still instead of the image (page title, page excerpt, etc).

One could argue that the article context is a surprise more often than not, because the fact that Mediaviewer is modal is a technical detail that users aren't necessarily aware of. I've seen countless cases where external websites use an article-with-mediaviewer-open URL when they credit a Commons photo. They probably don't know that they were encoding in that URL which article they found the photo on.

Alternative ideas:

• Flip it around: Have the address bar emulate the File-description page at https://en.wikipedia.org/wiki/File:Goddard-Modern-Times.jpg or https://en.wikipedia.org/wiki/File:Goddard-Modern-Times.jpg#/media/File:Goddard-Modern-Times.jpg. This has the downside, of course, of breaking a number of the user cases above. One could potentially regain those with a new parameter (a JS-only #-hash parameter that is, not a query string) to indicate which article should be navigated to upon closing the modal. E.g. "returnto" like https://en.wikipedia.org/wiki/File:Goddard-Modern-Times.jpg#/media/returnto/Paulette_Goddard. That would still break the gallery functionality, however. And per T426848, I'd like to move away from linking to or promoting the local/duplicate File- description pages, and browser restrictions prevent us from using a commons.wikimedia.org URL in the address bar.
• The native "Share" menu can be influenced by setting <link rel=canonical>. I've confirmed on iOS 26 that runtime changes are honored, including when they go to a different domain (example at https://people.wikimedia.org/~krinkle/link-share-override-T431181.html). So we could set that to the same Commons URL as the Mediaviewer "Share" widget. This of course breaks the gallery and article context, and does not affect address-bar copying.

These two alternative ideas could be combined. Note that today, when you use the native "Share" menu in a mobile browser, the Mediaviewer context is lost and only the article is shared. This happens because Safari favors the <link rel=canonical> value, which is without the current hash fragment. Between sharing onlhy the article and sharing the File-description page, the latter might be a net-win?