Hi Jack Krupansky, your understanding is correct.
The third ticket has some user impact and delivers some additional minor benefits
It depends how you view it. I recently found that defining my own MP (when it wraps another one especially) is not so trivial in solrconfig.xml. You could argue that for the majority of the users, this is a very advanced feature to have, and I would agree. But for those who want to write more advanced and tailored merge policies,
SOLR-8621 will allow them to do so quite easily. And the impact to the users who don't need it is marginal (see my previous comment).
The reason I quoted that sentence is because of the words minor benefits – it's a matter of perspective of course – if you will be facing the need to write a special MP, then this feature will have huge benefits for you. I know you don't argue about the need, but just wanted to give my own perspective on this.
As for UpgradeIndexMergePolicy you're right that it's a one-time operation and the main purpose is to allow you to upgrade all segments of your index to a newer format. You will likely only use it when you upgrade to 6.0 and you think (or know) that you still have segments created by 4.x code. Note, that that you upgraded your software to Solr 5.x doesn't mean that the existing indexes' segments were upgraded too!
But even for this one-time operation, you currently have no way to define UpgradeIndexMergePolicy in a <mergePolicy> element, since it needs to take a wrapped MP which will actually decide which segments to merge together etc. (i.e. create the merge plan). So even for this one time operation, you'd need to have
SOLR-8621 in place.
I don't view SOLR-4654 as an umbrella ticket at all, but more of a duplicate of this one.
SOLR-8621 lays the foundations for allowing users to define compound merge policies, and in this ticket we will add a SortingMergePolicyFactory. As you said, this only handles the indexing side of things, and there's still work to be done in order to make use of it during search (i.e. integrate EarlyTerminatingSortingCollector. Also, I'm pretty sure I saw in SolrIndexSearcher early termination by time (which sort of covers the second part of SOLR-4654), though I haven't seen it actually being used.