Each view controller in a storyboard has "Simulated Metrics" which you can see in the attributes inspector:

Some of these metrics are inferred (thus, inferred metrics).
As mentioned by @thesystem, if a given view controller is the destination of multiple segues, there could be differences between the simulated metrics of the source view controllers of the segues. To address these differences IB picks a segue to break the tie when resolving the inferred metrics for the destination view controller.
@rick-pastoor's conclusion that it's safe to remove the entire inferredMetricsTieBreakers
section is correct in that IB can just choose different tie-breaking segues. However, there is no guarantee that the new tie-breakers will lead to the same layout results in IB.*
For example, I had a situation in which, depending on the tie-breaking segue, a view controller was shown in IB either with or without a status bar. Its view maintained a height of 568pts in both cases, such that the position of the top layout guide kept changing. This snowballed into other undesired (and largely meaningless) changes to the frames of views constrained to the top layout guide.
Based on these observations, choosing both the new and old sets of inferred metrics is not advisable. Instead, remove both sets and then open the storyboard in IB to allow the ties to be broken before committing the merge. To avoid undesired frame changes due to a change in tie-breaking segue, pick some value other than "Inferred" for the relevant simulated metrics of the destination view controller. This will ensure that IB generates a consistent layout result.
* The results at runtime should be the same unless there is any logic that relies on the initial layout immediately after the view is unarchived.