As @masterworgen discovered by using ClosedXML.Report, there is an edge case causing a range to be unmerged.

Reproduction:

            var wb = new XLWorkbook("Template.xlsx");

            var range = wb.Worksheets.First().Range("A5:F5");
            range.Delete(XLShiftDeletedCells.ShiftCellsUp);

            wb.SaveAs("result.xlsx");

Original file:

Expected result:

Actual result:

Template.xlsx

This happens if there is a merged range of exactly same size just below a range to be deleted (with ShiftCellsUps mode), or to the right of it (when ShiftCellsLeft mode is used).

The reason of such a behavior is the usage of ranges repository: when all affected ranges are being adjusted in NotifyRangeShiftedRows/NotifyRangeShiftedColumns, first we update the merged range and it becomes the exact clone of the range to be deleted (therefore, they both are "optimized" by the repository to reference the same instance); and then the deleted range gets destoyed, together with the merged one.

In the PR, I am handling this edge case: if any range becomes identical to the original one then we don't have to process this range outside the loop.