The classic SPLIT/MERGE documentation is available at: https://cve.mitre.org/cve/editorial_policies/cd_abstraction.html
Basically there are three scenarios, one common, one occasionally and one that rarely happens (but will increase as time goes and more complex systems are deployed). One advantage of Open Source is that due to the vulnerable code and fix being public it is often much easier to classify vulnerabilities correctly.
#Classic SPLIT/MERGE
The classic SPLIT/MERGE works for clearly defined vulnerabilities (e.g. where the CWE is known, or the vulnerability is well understood). Basically if more than one vulnerability is reported by a researcher or organization the vulnerabilities are split up by affected code base, then vulnerability type (e.g. buffer overflow, cross-site scripting, buffer over read, etc.) and then by affected version. So you are left with groups of vulnerability that affect the same codebase, same versions, and are of the same vulnerability type.
#Intersection vulnerabilities
A new trend is intersection vulnerabilities. In certain cases two programs on their own may not contain a vulnerability but when used together may result in a vulnerability. For example a program that logs sensitive data to a file that has secure file permissions and a second program that is used to send crash reports including logs to a vendor for analysis when used together could result in potentially sensitive information being leaked. An example of this is CVE-2014-4039.
#Chained issues resulting in vulnerabilities
This is another new trend, some software is complex enough that multiple issues within a code base or multiple code bases can be chained together or used in conjunction to achieve an attack result.