ты точно все правильно написал?

да, считай что вью будет SomeView. Presenter1<SomeView>  и Presenter2<SomeView>. а инжектится или 1 или 2

внутри разная реализация одних и тех же методов

можно, но только будет одновременно 2 презентера

Если хочешь, чтобы презентер выбирался например в зависимости от аргументов фаргмента, то думаю можно это разрулить в providePresenter(), но нужно сделать чтобы у презентера был общий предок (один базовый тип). Я так не делал, но по идее должно работать.

Но думаю правильнее сделать просто разные экраны fragment+presenter.

60% кода такие же

а этот код именно вьюхе команды дает? а то может выделить в объект отдельный

и то и то

считай что просто переписано поведение presenter

ну это нормально. обычно объеденить хочется когда кажется что присутствует дублирование кода. Но тут нужно остарожно. Если мы точно знаем, что эти куски кода (предполагаемое дублирование) будет ВСЕГДА изменяться вместе и у них есть только одна причина для изменений, то да - вероятно это дублирование и стоит объеденить. Но в случае с экранами, очень часто эти презентеры будут иметь разные причины для изменений, и это не будет являтся дублированием кода и не стоит их объеденять. Это один из принцыпов solid - принцип единой ответственности. Просто когда придётся изменить чтото в одном экране, а они завязаны на один презентер, то мы тем самым внесём изменения косвенно и в другой экран - это плохо.

Как получить context в Preseneter?

никак
ето делать не надо

Пытаюсь инициилизировать интерфейс не получается

Он там не нужен

а как же  onCreate() ?

не

мне наоборот надо из презентера callback в Activity сделать

только через базовый