TL;DR: It ignores whatever the computer tells it to do and does an automatic detection.
And the reason? UART terminals are not doing flow control settings in a consistent way, and in some cases incorrectly. Therefore the JLink OB firmware will detect automatically if flow control is used. So the use of flow control will only depend on the target firmware.
It all started when I saw a weird issue with pyserial flow control, and after some digging I finally found out how things really worked. Read on for the full explanation.
The significant behavior is as follows:
As mentioned, one of the important design consideration for the nRF51 and nRF52 DKs is to allow accurate power measurements. When the UART is enabled it means that IOs are driven or set as inputs, and that will affect the result. A state where all the IOs are tri-stated is needed for this.
To enable the UART the only reliable signal you can get from a PC that a COM port is opened is the setting of the baud rate. The flow control settings are too varied and unreliable to consider.
Furthermore, some terminals will not send any notification when the port is closed. So there is no sure way to know if the computer program is done using the UART or expecting it to be available. Therefore the UART TX is disabled when the JLink OB is done transmitting, and re-enabled when there is new data to transmit. The RX will remain enabled until the OB is power cycled.
It was really hard to tell in my case, and I think the same thing applies in this case. When studying the problem I used USBlyzer while monitoring the 4 GPIO lines. That will at least give you some visibility on what goes on, for example if the RTS or CTS is not in the right state.
I'm afraid you have to do the debugging yourself. If you see any strange behavior that you can't explain I can check if there is a non-obvious design decision behind it, such as the need to do power measurements.