I think forced merges or forcing reclaiming of deletions, both invoked
by explicit app request, are very different use cases than the
"natural merging" Lucene does during indexing (not directly invoked by
the app, but as a side effect of other API calls).
So I think it makes sense that the MP has separate methods to handle
these very different use cases.
I don't thing we should use single param / single method XXXContext
approach to "bypass" back compat. We already tried this with
ScorerContext but backed it out because of the loss of type
safety... for expert APIs like this one I think it's actually good to
require apps to revisit their impls on upgrading, if we've added
parameters: it gives them a chance to improve their impls. Plus this
API is already marked @experimental...
Also, single method taking a single XXXContext obj means that method
will have to have a switch or bunch of if statements to handle what
are in fact very different use cases, which is rather awkward.
Still, separately I would love to make forceMerge/Deletes un-public so
you have to work harder to invoke them (eg maybe you invoke the merge
policy directly and then call IW.maybeMerge ... or something). We can
do that separately...