I haven't installed the plugin but glancing at the code I guess the issue you're talking about is that it doesn't modify the ^contentwords.type field. If that is the case, then it is not as serious as you might imagine.
That table is there for searching in a fast way. That particular field is used to sort the results. It gives more preponderance to questions (1), then answers (0.5) and finally comments and notes (0.25). Having these values improperly set would result in a different sorting than the core expects.
The thing is, when plugins modify the core data they generate risks to the user. In this case, what you detected, is a minor thing but I always wonder what has not been detected. Not to mention what will not be detected in future Q2A versions. E.G.: if the next Q2A version displays results of the matches in each post type and displays them with different colors for answers and comments, then the colors won't be displayed properly if the data in that table is used. This issue would be silly but there might be other more serious ones such as trying to access data present only in an answer (votes maybe?) that are not currently part of the comments.
My advice to implement that kind of plugin would be to reverse the process here. There are obviously some unneeded things such has handling the child posts. However, I think it is a good idea to give it a start. Particularly, focusing on indexing, which is crucial and does most of the dirty work. I would also add a note to make sure that the plugin should only run for the particular Q2A version in which that function would be based. I mean, if the qa_answer_to_comment() function adds some extra logic in future Q2A versions then the plugin would have to be updated accordingly.
