Actually, if the language is English, the text from tstrings.tbl isn't used at all (although the text from strings.tbl still is); the string preceding the index is used instead. This is true in both retail and current SCP builds (yes, I tested it just now).
Well, phooey. I tested this back in the day for a strings.tbl entry and assumed tstrings.tbl handled it the same way. A foolish inconsistency is the hobgoblin of code maintainers.
I don't quite understand what you're getting at here. A typical translation is going to be different from the original anyway; how would changing such a translation suddenly cause string lookup to start failing?
In other words, if you use the untranslated string as a string lookup, you're relying on something which is not actually the intended key of the table. If you are using the untranslated string to obtain the XSTR index using the translated English string, this relies on the equivalence of the untranslated and English strings.
How is storing the original string the wrong approach if you're also storing the translated string (and you've properly implemented the functions needed to deal with this)?
See the previous paragraph. It's not clear to me how you would link the untranslated string with a translated string (of any sort) without using the XSTR index. Your proposed dual-string struct seems like a transformation of the problem rather than a solution to it.