Hi Emily,
It can be done with a standard keyboard layout, but there is an intrinsic limitation:
A key can either be a dead key or a standard key, not both.
So you can’t have the best of both worlds, e.g. that the T should behave like a standard key before, say, consonants, but like a dead key before vowel letters.
That’s why Sorin basically suggests leaving the common keys alone and assigning the dead keys to another "level", e.g. holding down Option while typing a key.
An alternative approach to leave the common part of the keyboard alone:
You could have dead keys not for the consonants, but for the vowel letters, e.g. 5 dead keys on the digits row, with the digits bumped to Shift + those keys.
This way, you would need to type the vowel first, then the consonant – I don’t know if that is easy enough to learn.
The difference in behavior between standard keys and dead keys is hard to describe, it’s better to see it happen on the screen. But I’ll try:
• When you type a normal key, its character appears right away.
• When you type a dead key, its "terminal" character is displayed, while the computer waits for the second key.
After you type the next key, the terminal character disappears and the character defined for that combination of dead key and follow-up key is inserted – if there is such a definition.
If there isn’t, two characters are displayed: the terminal character of the dead state and the character typed.
Again, you have to try it in practice to know if this is good enough for your project, but my guess is that for a serious project, it’s better to have someone design and create a "real" input method.
(Apple also calls simple keyboard layouts, like Ukelele can edit, input methods, so I say "real" to distinguish from those.)
To get an idea how those (can) work, install an input method for a script you can read and experiment typing with that – maybe Tom Gewecke can recommend a language?