Currently, if you git-add a symlink copied from another git-annex, git-annex will 'fix' it so it points to where the files would be in its new annex object store, but doesn't create the corresponding file for the key on the git-annex branch, so git-annex doesn't actually "know" about the file.
This means running git annex reinject --known won't reinject the content for the symlink (e.g. "Not known content; skipping").
I tried running git-annex-fsck hoping it would create the file (with the information that 0 copies exist) but it doesn't do that..?
Any advice on how to go about resolving this? Preferably a "lightweight" way as this repository has a lot of such transplanted symlinks.. 
fsck sees that the (lack of) location log accurately states that the content is not present, and so avoids writing to the log.
If fsck always wrote to the log when content was not present, running fsck in sparse repos would bloat the location logs unncessarily.
But I suppose that it makes sense for fsck to notice that the key was not known and write to the log in this particular case. I've gone ahead and made that change.
It's not clear to me though, why this workflow of copying over symlinks, and adding them and reinjecting is better than just moving over content and adding it.
It protects against adding in corrupted files without noticing.
If I move the symlink as a real file, the receiving git-annex will rehash it and, if it is corrupted, effectively change the symlink to a corrupt file with no way to tell this has occured.
This method leaves the transplanted symlink broken (and may be fixed by a reinject of a good copy of the file from another drive) and the corrupt content would be left behind by the reinject. This makes it very obvious something has happened.
Thank you for making these changes to support my use case. I really hope it doesn't break anyone else's!