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

Ну думаю , чтобы можно было легко подменить реализацию

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

Ну вот тебе и ответ на твой вопрос. Ты так себе придумал.
Я бы посоветовал интересоваться причиной, а не следствием.
Подменить реализацию презентера? Это очень вряд ли. Точнее, в архитектуре это быть не может (имхо, тут не настаиваю).

Не было ни одного кейса когда надо было бы делать базовый презентер от MvpPresenter

Зачем? Можно поинтересоваться, что ты туда прячешь?

Ну и вброшу очевидное. У мокси в базовом классе есть логика, которая нужна для связывания вью и презентера

Если бы это было интерфейсом, то пришлось бы реализовывать её в каждом прямом наследнике

И реализовали бы неправильно.

Под базовым презентером я и подразумеваю этот MvpPresenter, просто я предложил методы attachView перенести в интерфейс (назовем IMvpPresenter) , а этот MvpPresenter уже реализует их правильно, так как Moxy решает верным. Теперь в интерфейсе  IMainPresenter я наследуюсь от уже реализованного в IMvpPresenter.   Далее мой презентер(MainPresenter) наследует MvpPresenter и реализует IMainPresenter.   Тут идем как бы наложение, не знаю как правильно в терминалогии это выразить, т.е. IMainPresenter имеет методы attachVIew, но повторно их реализовывать не нужно, потому что в MvpPresenter это уже сделано.  И получается , что не нужно в каждом наследнике реализовывать attachVIew заново, просто наследуем свой интерфейс от интерфейса MvpPresenter.     Ну и напоследок, даже если мы не будем подменять реализацию презентера, зачем лишать себя этой возможности, если сделать это очень просто? Тем более MVP предполагает такую возможность подменять презентеры. Снова скажете нафиг надо, но я скажу, а почему бы не оставить такую возможность для себя, если ничем не жертвуем ради этого.   Если сложно из моей писанины понять, о чем я , то посмотрите пожалуйста в моем проекте на примере активности MainMenu.  https://github.com/Turalllb/fixer.io_withRetrofit2AndDagger2/tree/master/ExchangeRates/app/src/main/java/mobiledimension/exchangerates

И вообще хотелось бы для начала узнать как вы думаете насчет: Зачем не оставить за собой возможность подмены презентера, если мы за это ничем не платим ? согласны с этим, если в цене нет, того что мы каждый раз должны реализовывать логику MvpPresenter?

Ерунда какая-то. Получается вы хотите интерфейс презентера, но все равно будете наследоваться от класса реализующего этот интерфейс. А все методы интерфейса просто пробросите в суперкласс. Зачем вам такая куча пустого кода?

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

НО ЗАЧЕМ? Какую задачу решит такой подход?

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

Что это может быть за беда https://gyazo.com/7c7c045945c9ab30e07bbe97bd6aa515 Это генерируемый мокси код,  MainMenu по указанному там пути это папка, в которой есть одноименный класс. Думал может проблема в том, что назвал одинаково, но переименование не решает вопрос.

1.5.5 используете? Установите 1.5.3, в нем нет бага со статическими интерфейсами

Да,  1.5.5. Спасибо

У меня такая в 1 фрагменте есть список, мы нажимаем на элемент и должно появиться 2 фрагмент. В общем из 1 во 2 передается id. Как это реализуется в Moxy. При нажатии в первый Presenter уходит id ,и что потом?

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