I have changed my mind on that:

(1) as the MergeBaseWalk uses its own RevCommit class (and this is reasonable for mentioned memory issues), it couldn't be combined with other RevWalk derivates. So there would be restrictions on when stopOnMergeBase may be used which are less obvious to the user than when having a separate MergeBaseWalk class.

(2) I didn't get the intention of MergeBaseGenerator right which actually only returns the merge base commit, but not all commits up to the merge base as MergeBaseWalk does. Still both problems are very similar and probably much code could be shared, but introducing some abstract class here serving both use cases would make the code even harder to understand.

(3) to address "reachability" issues as they are e.g. necessary for "git branch --contains" and "git branch --merge" a separate MergeBaseWalk is sufficient.