LP-MSPM0G3519: Confusion regarding UART_ERR_08 and DL_UART_changeConfig()

Part Number: LP-MSPM0G3519

Hello, 

in our project we want to interface to a half duplex UART connection. To avoid writing to the MCUs UART RX FIFO when transmitting data, UART direction should be changed to TX, and on end-of-transmission back to TX_RX. 

In the driverlib I stumbled across the DL_UART_ChangeConfig() function, which should be called before making any changes to UART CTL0 register, like changing the UART direction:

/**
 *  @brief      Prepares the UART to change the configuration
 *
 *  If the UART has already been enabled, then it is recommended to call this
 *  function before calling other APIs that make changes to the CTL0 register.
 *  If changes are made to the CTL0 register without disabling the UART, then
 *  results are unpredictable. This API performs the following:
 *  1. Disable the UART.
 *  2. Wait for the end of transmission or reception of the current character.
 *  3. Flush the transmit FIFO by clearing bit FEN in the UART control
 *  register CTL0.
 *
 *  @post After calling this API, the user must be re-enabled by calling
 *        @ref DL_UART_enable.
 *
 *  @param[in]  uart  Pointer to the register overlay for the peripheral
 */
__STATIC_INLINE void DL_UART_changeConfig(UART_Regs *uart)
{
    DL_UART_disable(uart);
    while (DL_UART_isBusy(uart)) {
        ;
    }
    DL_UART_disableFIFOs(uart);
}

I was wondering how this could work, since the UART is disabled first, which would prevent transmitting any data and therefore TXFIFO cannot be cleared anymore. Since STATE BUSY is set as soon as FIFO or TXDATA is non-empty and the Enable state does not have any influence on the STATE BUSY (see Errata UART_ERR_08) it seems to me just matter of time until I end up in the while loop forever.

It would be great if someone could either confirm this or explain to me where i got it wrong. 

Thanks in advance.