it looks to me like the NVT codes match with ASCII control codes, and the meanings of those are fairly standard, and normally act as they are described in that specification. I think you can pass them without translation (aside from the 850 style translation, if enabled)
Also, does the 850 support translation in concurrent mode? if it does, this normally happens in the R: handler. In concurrent mode, the 850 becomes a fancy level shifter, digitally copying serial RX to SIO TX and SIO RX to serial TX. In line mode, the 850 may do the translation.
Either way, I think the differences between RespeQts R: and the 850 is probably going to be different enough that at least a partial rewrite of the handler is going to be necessary, or at least beneficial. The 850, in concurrent mode, was a fairly dumb device limited by the lack of real UARTs, small RAM, and slow CPU. The 850, for these reasons, offloaded some things to the atari computer. However, these limitations aren't present within RespeQt, so we can do these things in RespeQt rather than on the atari. translation is the first example that comes to mind, but another example is that a FIFO can be implemented in RespeQt, unlike the 850 hardware which had no FIFO in concurrent mode. Some of these changes need no change to software (a FIFO would not break the 850's R: handler) but others do, like translation within RespeQt.
EDIT: additionally, you can assume that if the user is using a terminal that doesn't comply with NVT (ATASCII terminal for example), then the user knows what they are doing, and is also sure that the far end doesn't expect compliance with NVT and will instead cater to the needs of the client (send ATASCII characters for example).
Edited by Joey Z, Tue Apr 25, 2017 11:26 AM.