Speaking entirely as an armchair programmer here, that seems an imperfect solution -- by not toggling keypad(), you may be getting degenerate characters (like arrow keys...) fed into input stream and then echoed to the screen. You mentioned typing anomalies, so you may have already seen something like this.
Speculatively, the problem may be a result of incorrect handling of Windows newlines when you disable raw output in PDCurses. I would intuitively expect that to only affect the echo text though, not the input itself, and I really don't see how enabling (rather than disabling) translation would cause problems. My best suggestion would be to try to isolate it to one of the two changes -- either the raw_output(FALSE) or the keypad(stdscr, FALSE). Or have you already determined that it's specifically both, and commenting out only one or the other of them doesn't fix it?
The other thing I would try is making two string reads inside all the code sandwich for enabling/disabling echo and changing the translation settings. Given that you have unexpected behavior, and without knowing how the library was coded, I would test this before ruling out the possibility that merely toggling those settings back and forth between reads is messing something up.
One thing I can say with actual knowledge to back it up (rather than all the derpy "I don't actually know this stuff either, but here are some ideas" advice I've been offering up) is that your x and y are crossed in mvgetstr(). I know you acknowledge this, but I'm reading that acknowledgement as saying that you saw the y parameter first and mistakenly thought this was an error, so you switched them to make x first... when in fact, the y parameter does come first in Curses. I see a couple bad reasons and no good reasons to make the y parameter first, but apparently whoever wrote the original library thought otherwise.