I have been having a similar issue - one of my modules is working fine but one of them loses data and either one is sending data in bursts or one is receiving in bursts. The communication works fine to the boards they are on and communication to the modules from the boards also appears to be fine (tested with some series 1 modules) but communication with these modules isn’t working.
I have tried resetting the modules, changing the configuration of which is the coordinator and which is the end device but the problem persists. This also happens on all baud rates.
A mesh like Zigbee wasn’t designed to be used this way & there is a physical limit to how many packets can be sent per second from a single node. You are probably already creating too many small packets, so some are getting dropped.
Use something better than HyperTerminal (like Putty or others) which allow the tool to only send full lines of text. So when you hit , the full line is sent in a clean, continous stream. This will work quite reliably.
Will CTS/RTS help? Perhaps, but using the wrong tools is always troublesome, and it might cause other issues.
If you really want a remote dumb-terminal like this, then simple point-multi-point 802.15.4 XBee - which can use broadcasts - will work better. But you do not have the auto-mesh routing with 802.15.4. It is all line-of-sight.
Playing with the RO setting - making it large, could help in this situation as it would delay sending packets.
Foe example, the default of RO=3 means at 9600 baud packets are sent every 3 msec. of course a human can’t type that fast. So trying to bump this up to say 500 (1/2 second) or 1000 (1 second) could allow more bytes to piggy-back into the previous packet.
Note that RO is related to baud rate, so while at 9600 baud RO=1000 is 1 second, at 115Kbps it is only about 100 msec, so still outside of human typing ability.