After a few attempts, I noticed that the Hook links were kept when the linked files were deleted. For some people, it may certainly be a bug, but I find it rather useful!
The additional small wish would be that this information (deleted files) be (or can be) accessible from the linked files and also indicates where this file was located.
I give you my vision:
For my research, I use the Zotero reference manager. The files (research papers & notes) are stored on a Webdav server. Due to the limited space on the disk, I download the files when I need them (and delete them regularly when they are no longer needed).
So, when they are re-downloaded (from Zotero), I find my Hook links:)
However, from a working document, it might be useful to know that I had linked this (these) reference(s) and that I can then re-download it.
As it happens, the path of file path is noted below the filename (in the ACCESS LINKED ITEMS section). But as you note, there’s no indication that it’s unavailable. Well, if a file is in the trash, the pathname indicates that. But it’s not very prominent. And as you note, for some people this may be a problem. So we might make that an advanced preference.
Visually indicating that a file is no longer accessible would also be helpful for cloud storage services , like Dropbox and iCloud, as well as version control systems (like Git and SVN). Those are all important usages for Hook.
Fixed an issue that could lead to asymmetric links to/from some files.
But this was not specifically to deal with deleted files.
Hook does not know if the target of a non-file URI disappears. There is no macOS-wide protocol for Hook or any other app to subscribe to notifications about arbitrary resources (for events such as the resource being renamed or deleted). (However, we may help move this forward in the future.)
Similarly, if a link points to an https:// address which is no longer meaningfully populated by the server, Hook wouldn’t know. However, users can manually delete Hook links.