A user reported some surprise after the upgrade to Lucene 7.5 due to changes to how forced merges are selected when maxSegmentCount is greater than 1.
Before 7.5 forceMerge used to pick up the least amount of merging that would result in an index that has maxSegmentCount segments at most. Now that we share the same logic as regular merges, we are almost sure to pick a maxMergeAtOnceExplicit-segments merge (30 segments) given that merges that have more segments usually score better. This is due to the fact that natural merges assume that merges that run now save work for later, so the more segments get merged, the better. This assumption doesn't hold for forced merges that should run on read-only indices, so there won't be any future merging.