Take the case when a big chunk of some parent repository is taken as a mostly starting point for another child repository, deleted from the original, and made a submodule instead. (All of this has already been completed and is in the past now.)
I see that .git/info/grafts would allow one to preserve the history for git-blame and git-annotate, and can possibly be employed ex post facto.
However, what if the files are not exactly the same? E.g. one version was deleted from the old original parent repo, and a slightly modified version was committed to the new submodule child one? Can a reference still be made? Especially if both repositories continue to be updated, and one would rather not have to deal with re-writing any past history (any more than need be).
Commits do not hold references to diffs, they hold references to trees, where a tree is basically what your working directory should look like. If you have commit A with tree 1, and commit B with tree 2, then when you ask to show the diff between A and B, git calculates the diff between tree 1 and tree 2.
From this, it should be a bit clearer that it doesn't matter that files aren't 100% identical when grafting. However, if they aren't 100% identical, any differences will (correctly) be shown when you ask to show the commit.
Note that although this is generally unrelated to submodules, submodules use independent gitdirs, so the parent history is not automatically available. You will need to make sure to fetch the required history before grafting will have any chance of working. Also, grafting is a local operation. Others cloning your repository won't have an option of getting the grafts. You may consider
git replaceinstead, which uses regular refs, and which should be fetchable by others who want them.