As the original author of gtypist way back, I have spent the past two decades in some embarrassment at the quality of the code I wrote back then. This finally got the better of me, to the point where I sat down recently and rewrote large pieces of it to be more maintainable and modular.
I only have to hand an old Mac PowerBook that does not build gtypist cleanly, so my starting point was the initial drop of typist to gtypist. Because of this, much of the work that has gone in to gtypist since then is either absent from my newer version -- for example, wide character support; I have not tackled this yet -- or I have re-implemented as a decent facsimile of the feature -- proper menus, on-failure labels, etc. That means my re-work cannot be a drop-in replacement for the current gtypist code. More of a 'fork', I guess.
However... there may be a few features in my work that you can reasonably (or perhaps, very) easily port forwards into the current gtypist and which might be useful, and if you are interested then you are more than welcome to do so. Just let me know, and I will send the sources through for you.
To pique your interest, the new code includes: a fully re-entrant interpreter so that scripts can run other scripts; JSON format lessons, for better data portability; a purely declarative lesson format (no more goto's!); the ability to emulate other keyboard layouts directly and without having to set them in the OS; infinite loop detection; better string hashing; improved debugging (eg tracing interpreter actions); an attempt at C namespaces; and recovery on script or input errors. And of course, improved readability and modularity, and close to full backwards and sideways compatibility.
Of these, it will be tricky to add re-entrancy to gtypist, and JSON would be a sizeable project that might not be worth the effort (I used this re-implementation to try out a few ideas I had bubbling around in my head, some more successfully than others!).
Emulating other keyboard layouts, on the other hand, should be fairly easy. The new version uses JSON to hold layouts, but it would be fairly easy to 'bake in' the parsed JSON layouts into gtypist, and so offer a decent selection of hard-coded layouts without too much effort -- ultimately, all this emulation boils down to is: for each keypress, find the key position on the keyboard you have, and then look up the character associated with that position on the one being emulated and use that instead.
Tracing the interpreter should also be easy to add. Infinite loop detection is trivial. The C 'namespaces' are fiddly to retro-fit to anything, but perhaps moving the curses stuff out to a separate module might be worth considering, to keep all the curses macro definition and other curses 'noise' out of the main code.
And please update the string hash in gtypist :-). I had no good idea of how to hash strings well when I wrote the first version, but I do now. Moving to a prime number of hash buckets would also be worthwhile, I guess.