Actually, my program works on a 8MHz basis - it should be more than enough to handle 9600bps serial data, no?
probably not , on interrupt is not suitable for processing async data streams in any useful way without flow control
if there is a "real" foreground task being processed incurring data loss is inevitable

Since you refer to it, why is there a buffer of "2" characters? What's its use?
a simple fifo buffer gives you a little bit more time to process the rx data without loss
@9600 its about 100uS at best

I will always have unknown data length (I'll read sms messages)
to approach a task like that you need to have a good understanding of what the message data will look like
eg is there a start chr? is there and end chr eg /n or /r , does the message have its length encoded in it? is there a chksum or crc
what is the maximum and minimum length

there is zero benefit in having an isr capture one chr at a time then immediately pass it back to the foreground task.
your isr would ideally allow the foreground tasks proceed unhindered by the rx process until a message was
received and ready to process


dt ints is not difficult the forum abounds with examples