If there are multiple exploits, each not accomplishing anything significant on their own (but are still technically exploits), but when used together in an exploit chain can achieve a meaningful result, would the entire chain of them be eligible for A CVE or would each of the individual one be eligible?
multiple exploits, each not accomplishing anything significant on their own
So, an exploit is when you get the system to behave in a way that is contrary to its design and documentation.
Let's use an example. Suppose you can convince a system to flip a bit in memory somewhere that doesn't have a specific value it's supposed to be---maybe because it's in an unallocated region at the moment. If you are authorized to allocate or use memory on the system, that's probably not an exploit, but it would still be an exploit if their design/specification forbids that behavior. If you are not supposed to be capable of doing that, then it's an exploit regardless of its practicality.
If you need 10 steps to fully exploit a system, it's possible---and fairly common---for 2-3 of those actions to be actual exploits while the other 7-8 steps are setup work or post-exploit configuration.
So, look at your list of "exploits" and ask for each one: "Given the state of the system before I take this step, should I be able to do it?"
If the answer is "Yes, this is permissible" then that action is a prep/post step. If it's a No, then it's an exploit.
Depending on the target, it may help to contact the vendor with your proof of concept code. Their documentation, support staff, or security team should be able to clarify where the software is not acting as intended. At each point where this is the case, you would submit a separate CVE.
On their end, the vendor may patch your CVEs individually or in a single release, but that has no bearing on the number of vulnerabilities/CVEs.
would the entire chain of them be eligible for A CVE or would each of the individual one be eligible?
Each CVE is intended to represent a single vulnerability. Potential CVEs are more likely to be split up for finer granularity than merged.
The current guidance for this process is the Process to Correct Counting Issues, and the section on merging only describes using it to address "resolving multiple CVE IDs assigned to a single vulnerability". A merge is not intended to describe a chain of vulnerabilities.