Большое спасибо,
За советы.
Я разобрался в своём вопросе.
Пишу это, для того, чтобы помочь другим новичкам вроде меня избежать аналогичных проблем.

В моём случае имела место совокупность ошибок:
1. Прерывание приёма на самом деле всё-таки возникало всё это время, однако, в конце кода его обработки (к сожалению, рассматривать её как источник ошибок я стал слишком поздно) стояла строка вида UCSRB = UCSRB | (1<<UDRIE); разрешающая прерывания освобождения буфера USART, обработчик которого не был объявлен, что является багом. Это вызывало циклический RESERT МК, напрочь стирая все следы возникновения прерываний. Нужно было внимательнее партировать код из доступного примера
2. после того, как я исправил это, USART всё равно принимал/посылал кашу. Виной было то, что я упустил из виду хрестоматийную истину о важности точного клока для UART – я использовал внутренний генератор системного клока для ATMega8L, который по даташиту «не надёжен». Как только я запаял внешний кварцевый резонатор – всё заработало как надо.

Удачи всём тем, кто работает с USART’ом.
И большое спасибо всем откликнувшимся!

По даташиту он "с завода с точностью +/-3%" для Vcc=5В и температуры 25гр. В принципе должно хватать(+/-5% достаточно) и с температурой меняется не сильно. Но скорее всего у Вас не 5В, а 3В при которых частота 1.9МГц +/-3% т.е. еще на 5% ниже.
Проблема может решаться алгоритмом автокаллибровки по символам из потока если внешнее устройство первым при включении начинает обмен.

Да у меня именно 3В и шла каша.



Автокаллибровка – классная идея, спасибо, возьму на вооружение, на будущее. Типа, когда приёмник в начале калибровки знает, что посылает источник, т.е. первые N пакетов и «устанавливает таблицу соответствия».

Достаточно одного символа в котором N фронтов между которыми меряешь времянку. Перепады можно мерять прерыванием по изменению порта (PCINT).

Никак не возьму в толк как может помочь знание таймингов между фронтами в 1 посылке?

Вот посмотрите это. И пример применения.

Большое спасибо!
Обязательно посмотрю.