The CCR hasn't actually been assessed to have S2 (minor) severity. What's happened is that it has been duplicated with earlier requests for this functionality. In fact it's now a member of a set of 4 duplicate CCRs - two of which are for merging the troubleshoot point results with the run they originated from, but the master is for a general request to be able to merge the results from any two runs (for example, you might have run with one sweep - and then run with another couple of points, but want to see the complete set merged together). Since the results for troubleshoot point are a different history point, effectively it's covered by the more general request.
However, the original requester for the general result merging filed it as an S2, and R&D at the time accepted that assessment of the severity.
Typically as duplicates come along, they get duplicated but nobody sits and reassesses the master's severity as the duplication is done. Instead, this happens during one of the periodic planning reviews as work is decided upon for an upcoming release. Then the severity and status etc will get updated accordingly. It just means it's done in the light of how many other issues with more (or less) impact have come up in the meantime - rather than just an impulse response on the day of a CCR being filed.
Given that 3 of the 4 duplicates were filed as S1, I've asked R&D/PE to update the master's reviewed severity to be S1 rather than S2 (and so you'd then see that severity on your CCR too - because the master data is visible on all duplicates).
The good news is that there are now already 4 in the set, so that's a good start! However, I should point out that implementing a result merging capability is not as trivial as it sounds - because there's the vital task needed of ensuring consistency in the results (less of a problem with troubleshoot point than the more general merging case).