Краткий ответ

Такое объявление завершится ошибкой компиляции. При встраивании интерфейсов Go объединяет их методы, но методы с одинаковыми именами обязаны иметь полностью одинаковые сигнатуры. Go не поддерживает перегрузку методов и не выбирает одну из конфликтующих версий.

Исторический контекст

Интерфейсы в Go предназначены для описания небольших контрактов и их композиции. Встраивание позволяет собрать более крупный контракт из независимых интерфейсов без явного наследования и без привязки к конкретной иерархии типов.

Чтобы такой контракт оставался однозначным, одинаковые методы из встроенных интерфейсов должны означать одну и ту же операцию. Автоматическое разрешение конфликтов потребовало бы правил перегрузки или приоритетов, которых в модели методов Go нет.

Постановка проблемы

Рассмотрим ситуацию, когда один интерфейс требует метод M с параметром типа int, а другой — метод M с параметром типа string. Композитный интерфейс должен был бы одновременно требовать два разных метода с одним именем.

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

Подробное решение

При встраивании интерфейсов Go формирует объединённый набор требований. Если одинаково названные методы имеют одинаковые сигнатуры, они считаются одним требованием. Если сигнатуры различаются хотя бы типом параметра, результатом или получателем, объявление интерфейса недопустимо.

type A interface {
	M(int)
}

type B interface {
	M(string)
}

type C interface {
	A
	B
}

В данном примере компилятор сообщит о конфликте метода M. Нельзя реализовать C двумя отдельными методами с одинаковым именем: Go не поддерживает перегрузку, а выбор метода по типу аргумента не является частью вызова метода.

Если сигнатуры совпадают, композиция корректна: C будет требовать один метод M с этой сигнатурой. Если конфликтующие контракты принадлежат внешним пакетам, обычно применяют адаптер с другим именем метода, разделяют интерфейсы или меняют границу абстракции.

Важно, что встраивание интерфейса не добавляет реализацию метода. Оно только включает требования встроенного интерфейса в контракт внешнего. Конкретный тип всё равно должен самостоятельно предоставить подходящие методы.

Ситуация из практики

В библиотеке хранилища два интерфейса случайно объявили метод Load: один принимает идентификатор записи, другой — имя файла. Попытка объединить их в единый интерфейс привела к ошибке компиляции.

Вариант с переименованием методов устраняет неоднозначность и делает назначение вызова очевидным, но требует изменить публичный API. Адаптер сохраняет исходные интерфейсы и изолирует несовместимость, однако добавляет код преобразования и дополнительный слой.

Разделение интерфейсов обычно предпочтительнее, если потребителям не нужны оба контракта одновременно. В данном случае выбрали два независимых интерфейса и отдельные адаптеры на границах системы: библиотека сохранила совместимость, а конфликтующие операции получили явные имена в местах использования.

Что кандидаты часто упускают

Допустимо ли встраивание двух интерфейсов с одинаковым методом и одинаковой сигнатурой?

Да. Совпадающие требования объединяются в одно. Например, если оба интерфейса требуют M(int), композитный интерфейс корректен и по-прежнему требует один метод M(int).
Можно ли реализовать конфликтующий композитный интерфейс двумя методами с одним именем?

Нет. Такой композитный интерфейс сам не может быть объявлен, поэтому вопрос о соответствии конкретного типа ему не возникает. Кроме того, Go не позволяет объявить в одном типе два метода с одинаковым именем, даже если их сигнатуры различаются.
Передаёт ли встроенный интерфейс реализацию своих методов внешнему интерфейсу?

Нет. Встраивание интерфейса работает только на уровне требований. Если тип удовлетворяет встроенному интерфейсу, это не делает его автоматически реализацией другого интерфейса и не создаёт делегирование вызовов.

Например, композитный интерфейс может объединять методы Read и Write, но конкретный тип обязан предоставить оба метода самостоятельно. Для переиспользования реализации нужно явно встроить конкретный тип или написать делегирующие методы, что является отдельным механизмом.