КТО ЭТО ВАМ СКАЗАЛ???!!!
Вот сейчас, в простом проекте мне нужно сугубо параллельно работать и с отображением алфавитно-цифровой информации на индикаторах, и от клавиатуры нажатия ловить (причём, без прерываний, а только методом динамического-опроса-сканирования матрицы контактов), и с флэшкой работать (эмулируя и поддерживая фат16), и лить информацию по параллельному каналу, и ещё следить за кучей параметров (от отслеживания напряжения на акк.батарее и до температуры в корпусе) и большинство из них, так же, вынужденно опрашивается а не по прерываниям...
И мне бы очень пригодился формализм описания всего этого хозяйства, как взаимодействующих и выполняющихся параллельно сущностей!

Распараллеливание вычислений совершенно не характерно для микроконтроллеров. Им не приходится решать такие задачи ...

Язык программирования, на котором описываются распараллеливаемые (чуть язык не сломал!) вычисления, должен иметь конструкции для описания разбиения задач на параллельные подзадачи, где это невозможно сделать автоматически.

Компилятор должен обладать средствами автоматического разбиения задач на параллельные подзадачи, где это возможно.

До недавнего времени распараллеливание вычислений было головной болью специалистов в узких областях, но сейчас происходит вытеснение одноядерных процессоров общего назначения многоядерными на обычных персоналках, так как достигнут практический предел увеличения тактовой частоты. Поэтому распараллеливание вычислений становится распространенным явлением. Это и есть "вызов" языкам программирования.

...
Что значит – ОБЪЁМНЫЕ задачи?

Тогда на вас ложиться огромный труд научить компилятор зачаткам понятий из вашей предметной области... :о))))) Будем писать экспертную систему для обучения компиляторов? :о)

Нет никакого вызова. Если не изменится отношение к решениям задач максимум на что сподигнуться «распараллеливатели» - разнесением задач Оси и пользователей по отдельным исполняющим устройствам... И не на уровне языка описание будет, а, всё та же песня – на уровне библиотек и «пришлёпок»...

Забыл добавить самое важное )

Теперь в Обероне INTEGER явно объявлен как 32-битовый, а SHORTINT и LONGINT исключены совсем (что, считаю, правильно для "общего знаменателя").

Так SYSTEM.BYTE нихто не отменял...

А вообще, при реализации компилятора под конкретную платформу никто не мешает добавить тип данных для этой платформы...

Вирт, между прочим, с Oberon SA для встроенных применений вполне мудро поступил - получил язык, который непосредственно отображается на Strong-ARM, как С на PDP некогда...

Наконец-то Вирт убрал RETURN, который, как и GOTO, противоречит правилам структурного программирования. Это был единственный серьезный ляпсус.

...так что пока явного "можно выкладывать!" не поступило.

Не как GOTO -- про RETURN всегда ясно, куда он прыгает.
И не единственный -- EXIT в LOOP имеет ту же природу.

RETURN -- это фактически GOTO END, разве не так?

Проблема GOTO и RETURN в том, что программа "выпрыгивает" с любого уровня вложенности операторов на самый верх, создавая разрывы в логике, которые трудно отследить.

к тому же не имеет аргументов и не может создать ошибку (например, переполнения, при выполнении выражения RETURN A+B).

Не так. RETURN - это возврат результата. Больше ничего. Усматривать тут GOTO - это паранойя.
Странная у вас логика. Никто никуда не прыгает, функция возвращает результат. С точки зрения вызывающего кода точка возврата одна. Вас не пугает оператор IF? Он тоже "прыгает" в ветку ELSE (которая в случае принципиального отказа от RETURN может оказаться довольно "далеко" и слабо различима на фоне кучи других вложенных IF).
Ошибку выполнения создает не оператор RETURN, а выражение. result := A + B; EXIT; создаст точно такую же ошибку.

Оператор RETURN -- это прежде всего передача управления. Смысл моих утверждений был в том, что не должно существовать операторов передачи управления между несколькими составными операторами.

Нельзя из одного составного оператора "входить" в другой (это позволяет GOTO) и нельзя "выходить" сразу из нескольких составных операторов (это позволяет RETURN).

Слово "нельзя" здесь и далее означает не "Вам нельзя", не "никому нельзя", а некое правило, которое можно спокойно обсуждать и ставить под сомнение Из своего опыта я понял, что это правило очень облегчает анализ написанного чужого кода.

На мой взгляд, RETURN ничем не нарушает принципов структурного программирования.
Смотрите: при выходе из цикла мы переходим к оператору, непосредственно следующему за циклом.
При возврате из процедуры -- к оператору, непосредственно следующему за оператором вызова процедуры.