Для начала, я бы слегка упростил систему описания блоков команд (сейчас в разных видах это присутствует в теле модуля, в теле процедуры, в теле IF, WHILE...), можно это всё унифицировать, что откроет путь к поддержке параллелизма, асинхронности и кложурности, но на уровне, близком к описанию машинной организации фреймов и т.д. Потому что если посмотреть на это всё здраво, то это одно и то же, модуль это процедура, процедура это блок команд и т.д. Просто модуль это такая процедура, которую ядро зачем-то запомнило, как главную. Вот. Все блоки команд снабдить обязательным описанием предусловий и постусловий, входными выходными и регистровыми параметрами, забыть про т.н. "функции" и закрыть этот вопрос. Тут вот многим кажется, что наоборот, надо идти к функциональности, к тому, что всё есть выражение и вообще вся программа это одно выражение, мне вот кажется, надо наоборот.

именно это "слегка" обеспечило победу Питону.

Чиво-чиво???

Хорошо известно, что определение ошибки тем более затруднено и дороже обходится, чем позже она обнаруживается, т.е. чем дальше разнесены источник и его эффекты. Это позволяет сформулировать правило:

Позволяйте ошибкам заявлять о себе как можно раньше.

В компонентно-ориентированных системах дефекты всегда должны содержаться в их компонентах и не распространяться на другие компоненты. Другие компоненты даже могут быть черными ящиками и не иметь исходных текстов, что делает отладку на уровне исходных текстов невозможной. Более того, поток передачи управления в больших объектно-ориентированных программных системах настолько запутанный, что нереально, и это пустая трата времени, проследить его за пределами границ компонентов для целей отладки.

Единственный жизнеспособный отладочный подход есть проектирование всего, от языка программирования до библиотек, до компонентов и приложений, используя оборонительный стиль программирования. В частности, входные точки в компоненты (вызовы процедур/методов) должны останавливать исполнение, если их предусловия не обеспечены:

Никогда не позволяйте ошибкам проникать сквозь границы компонентов.

К счастью, большинство проверок предусловий недорого и поэтому их отключение при исполнении не имеет смысла. Это важно, поскольку в компонентно-ориентированной системе проверки этапа исполнения не могут быть выключены в конечной (готовой) системе, поэтому разрабатываемая и готовая системы не различаются. На практике большинство компонентов уже отлажено в режиме черного ящика («продукция»), а другие отлаживаются в режиме белого ящика. Готовые компоненты должны взаимодействовать, чтобы доказать приверженность сформулированному выше правилу, которое означает «никогда не отключать проверки этапа исполнения».

Блэкбокс Компонент Буилдер переводится = Построитель Компонент — Черных Ящиков.

BlackBox Component Builder я бы перевел Построитель Компонент — Черных Ящиков.
И на английском не хватает буквы "s"... BlackBox Components Builder

Да, некоторых слово Pascal вводит в заблуждение