If it could be just a thought you told about then I would be happy but:

This is from AT89S2051 and AT89S4051 Errata:

2. Read-Modify-Write to SCON (SETB, CLR, CPL, ANL, ORL, XRL, JBC)
Read-Modify-Write (RMW) instructions may cause a loss of
UART interrupt information if used with any bit in SCON,
i.e. the RMW instructions need to be treated as a direct move
to SCON such as MOV SCON,#IMM. These instructions may be used
when it is not possible for the interrupt to occur at the same
time as the instruction is being executed, which means in
the following circumstances:
A. The UART is not currently operating, or
B. Within a short period of time after TI or RI is set during
half-duplex communications, or
C. Within a short period of time after both TI and RI are set
during full-duplex communications, and before the next byte
is transmitted.

By other words, they notify their unfortunate users that this is not safe to use CLR RI, JBC TI etc).
This may cause total nightmare when both transmit and direct tasks are processed simulateneously (independent on each other).

I have do next workarond (altough Atmel does not confirm the trick yet):

;=======================================================;
; UART interrupt routine				;
;=======================================================;
PUBLIC	INT_UART
INT_UART:
#ifdef _AT89S2051_
; workaround of errata 2 (RMW SCON)
	PUSH	ACC
	MOV	A,#01010000b			; current UART mode
	XCH	A,SCON
	JB	ACC.0,INT_UART_RX		; RI
	JNB	ACC.1,INT_UART_END		; ! TI
; end of transmit a byte
INT_UART_TX:
;
; check transmit counter,
; initiate new transmit or finish current packet here
;
	JMP	INT_UART_END
; new byte has been received
INT_UART_RX:
; save it to a buffer (keep ACC not touched!)
	JB	ACC.1,INT_UART_TX		; TI was done as well
INT_UART_END:
	POP	ACC
	RETI
#else
; standart routine for AT89C2051

#endif

Sadly but works. Maybe because XCH is too short? (=
The hint is that both flags are cleared by XCH instruction and then ones are checked one-by-one. But due my knowledge of interrupt processing - it is still not safe. Read: code should not be used as workarond! (In my case there is just additional handshake/CRC of a packet so it is resended anyway if a trouble occured).

Regards,
Oleg