Да, есть такое. В принципе норм, сойдёт. Хотя странно, что методы - это хрен знает что. Такой жирный кусок функционала... Наверное, это в действительности с т.з. ООП часть AST компилятора и получить доступ к ней можно только из макросов.
Перегрузка методов: в Crystal можно иметь много методов, различающихся только типами аргументов. (а ещё, передан или нет блок). Т.е. та же проблема, что и в C++.
Чтобы взять ссылку на конкретный метод, нужно как-то указать типы всех его аргументов.
В Go есть ещё интерфейсы. Чтобы структура удовлетворяла интерфейсу, нужно объявить на ней методы. И эта штука будет проверяться не только во время компиляции, но и в рантайме (когда кастишь один интерфейс к другому).
Ну, везде есть недостатки :) Меня в данном случае удивляет именно отход от фундаментальной концепции про то, что любая сущность программы - это объект. Но с другой стороны если считать, что методы - часть AST, то всё становится на свои места
Если честно, не знаю. Но и как это поможет в обработке x.send(dynamic_name) ? Если в рантайме пытаться резолвить по типам аргументов, быстро не будет. А вы вряд ли ожидаете от Crystal «быстро не будет». Всё-таки лучше разруливать такой маппинг своими силами: и типы подогнать/продумать можно, и лишнего в маппинг не попадёт.