Currently when a page is deleted on a client the sitelink is also deleted on the repo. When the page is undeleted, the link should be restored
Another way is to allow not to remove sitelinks while deleting. This way has side benefit (e.g. link will not be lost while moving an temproary page to the main one), but is not useful for normal page deletion (noboby can predict when the deletion review happens).
I think this is to much work, for to little benefit. What we could possible do is to delay the execution of the jobs that update the repo so that immediate restores/ recreations aren't propagated. But I'm not sure that's desired.
Another usecase: In zhwiki all copyvio will tag as {{copyvio}} and be deleted 7 days later. They can be rewritten in a /temp page. When /temp page is moved to main article, the interwiki link is lost.
But those are different pages, thus it wouldn't be semantically correct to restore such a site link.
I think i that we need users to confirm whether the re-created page is connected to other pages via interlanguage links.
The check has to be only for re-created pages and be something like:
"This page is re-created. A deleted version of this page was connected to item Qxxxxxx in Wikidata. Do you want to attach this file with this item? Y/N"
I think one possible way of doing this would be to store in the local wiki page metadata the associated Wikidata ID. The existence of this could be used as a trigger to display the dialog suggested by Magioladitis above.
If it has been associated with more than one data item in the past, it could list all or only the most recent.
If the Wikidata item has been linked to something else on the same wiki in the meanwhile, then I think something should be promtped at the Wikidata end (note to whoever next edits the entry? post on the item talk page? entry in a list?) for a WD contributor to review which is the better link.
History-merging pages on enwiki is enough of a pain already (delete and restore are slow, and often time out and need to be repeated) and having to tend to Wikidata on top of that just adds to the trouble.
https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_guide/Fixing_cut-and-paste_moves#Bugs_and_problems
Has this bug been fixed (or almost fixed) recently as a side effect of something else? I've done several history merges involving deleting and restoring pages (e.g. "lorazepam" (Q408265) and fresh water (Q102192)) and haven't noticed this problem lately.
It obviously hasn't ... the problem still occurred here:
https://www.wikidata.org/w/index.php?title=Q615468&diff=prev&oldid=1081872742