AddressPresenter это конечно упорото

AddrStringer недостаточно точно

однако я бы всё-таки назвал net.Addr - net.AddrStringer 🤔

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

я понимаю

но наверное стоит таки придерживаться той идеология, что имя интерфейса должно отображать, что этот интерфейс делает/умеет делать, т.е. актора

ну а net.Conn - net.ConnectionHandler или net.ConnHandler

Мне кажется в зависимости от того, для чего вы используете интерфейс. Если в качестве протокола, то да, лучше дать явное название чтобы было понятно, что он умеет делать, но если в качестве абстрактного типа, тогда, он определенно должен отражать название абстрактного типа.

однако, стоит учитывая что net.Conn может являться сокращением выше предложенных

а можно хороший пример того, когда интерфейс отображает именно абстрактную сущность?

Выше например  net.Conn В документации даже сразу указано: Conn is a generic stream-oriented network connection. Я бы конечно назвал net.Connection но американци любят сокращать, особенно старые системщики типа Пайка.

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

ИМХО это не идиоматический подход. Интерфейс представляет собой актора над соединением, а не само соединение.
самый банальный пример того как бы можно было сиё чудо прозвать я привёл выше (net.ConnectionHandler или просто net.ConnHandler)

как мы уже выяснили, стд. библиотека далеко не всегда идиоматична

Там все нормально, они используют свой родной язык, я не вижу там противоречий. Я бы ни когда не называл net.Conn обработчиком. Это нэйтива сразу воглано бы в ступор, потому что это не обработчик. Это абстрактное подключение.

Я если честно не понимаю, почему вы решили что интерфейсы в Go чем то отличаются концептуально от любых других интерфейсов. Назначение во всех ЯП у интерфейсов одно и то же как по мне. Детали реализации могут отличатся но это детали, они сути не меняют. Есть несколько юзкейсов для интерфейсов в зависимости от того как они реализованы в ЯП. Это может быть абстрактный тип данных а может быть протокол. И то и другое используется в Go.

Короче говоря, это сугубо лингвистический вопрос, ни чего общего ни с Go ни с идиоматичностью не имеющий, как по мне.

Даже само слово idiomatic из лингвистики взято и означает: использование выражений, которые являются естественными для носителя языка.

Вы можете попробовать пойти к авторам Go и спросить, почему например они назвали net.Conn именно так а не например net.ConnHandler. Но думаю вы их изрядно озадачите таким вопросом.

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

вот если бы у нас было нечто поxожее на:

type Person interface {
 Name string
}

type Clerk struct {
 Name string
 Department string
}

type Medic struct {
 Name string
 Patients []Person
}

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

сущность ИМХО это в первую очередь про данные, не про функционал

> Даже само слово idiomatic из лингвистики взято и означает: использование выражений, которые являются естественными для носителя языка.

тут всё верно