My guess (for why the rules were merged) was that someone complained about the same code being reported twice, or maybe one of your devs thought people might complain.
Indeed, I reported a case of one rule being a strict subset of another rule (Difference between java:S1158 and java:S2131?), where a violation of one rule was always flagged under the other rule as well (but not vice versa necessarily). But in that case it appears both rules were picking out something straightforward with few (if any) FP, so it was a simple case for us to turn off the narrower rule.
One solution would be some kind of accounting, like “don’t flag this under rule X (e.g. S2250) if it’s also flagged under rule Y (S1697)” which would depend on factors like whether both rules are on (so, if S1697 is deactivated then should a violation of that rule still be counted as S2259?). Probably would need to be done in the post-scanning analysis phase in the SQ server. And then maybe you’d need something in the rule description to mention these cases.