Новые Go-шные "контракты" (в стиле плюсовых концептов в предполагаемом начальном виде) пока вызывают вопросы. К примеру, непонятно как задать абстрактный тип, скажем, вещественный без конкретики. Указать в контракте преобразование (приведение) к какому-то вещественному значению -- вроде бы возникает иной контекст (в таком случае подразумевается именно возможность (совместимость) преобразование значения). Указать конкретное значение (константу) вида "v = 0.0" -- вроде бы также возникает иной контекст (допустимость конкретного значения, в случае указания двух значений (в виде двух операций присваивания) подразумевается какое-то "непонятное понятие" диапазона значений). В общем, необходимо ещё разбираться (м.б. и разработчикам также).

А в целом, с дженериками Go-шная система типизации существенно "усиливается", для полностью "безтиповых" аргументов (без контракта) допустимы лишь ограниченные, предельно общие над типами операции. К примеру, вроде бы как, без указания "протокола о намерениях" произвольное преобразование или тестирование типа не произвести, что существенно разнится  от обероновской методики применения универсальных ANYPTR, ANYREC да и прочих приёмов "динамической типизации".

Для Оберон-семейства в контексте "смотрите, от чего я ради вас уклонился" -- отсутствие дженериков или их какая-то альтернатива и связанная с ними сложность. В самом деле, на сложности полно акцента в тех же статьях про дженерики в Go по ссылкам выше. Попытка упростить (прежде всего с оглядкой на С++) и подтолкнула Go-шников к такому дизайну (в котором, к слову, возникает теперь сплошь и рядом необходимость в "структурной эквивалентности" между контрактами, т.е. один и тот же метод и пр. "требуют" или могут "требовать" множество контрактов, собственно то, сплошная "статическая утиная" типизация в целом характерна в Go).
В контексте же "тотальной статической типизации" (где-то здесь на форуме определен какой-то такой тезис) -- предоставляются разработчику в пользование runtime-средства (плюс встроенные системные) для диагностики с крушением программы/системы в случае нарушений, что, конечно же, лучше неопределенного поведения.
С другой стороны, системы со "сложными дженериками" пытаются приобрести (с 70-х годов, в статьях выше про Go-шные дженерики есть исторический обзор) в том числе и "тотальность" иного плана -- максимально выявлять проблемы ещё в compiletime в меру потенциальных возможностей и минимизация потребности в runtime-проверках (плюс вопросы эффективности, производительности и пр.).

И вопрос "как лучше организовать полиморифзм?" на самом деле не простой, однако.