The O(ut) O(f the) B(box)/OOB solution to "link" changes to incidents is based on the premise that a single Change Request will "fix" an Incident. Thus when one uses the "Create Normal|Standard|Emergency Change" form context menu UI Action, the created Change will receive no reference to the creator Incident. Only the Incident will be updated to point to the created Change Request (via the Change Request field I mentioned previously). In fact as soon as one uses the "Create X Change" form context menu and the Incident's "Change Request" field receives a value, those "Create X Change" menu items are no longer shown.

Long story short, if you need to "link" multiple fixer Change Requests to a single Incident, you will need to come up with a custom solution. Either an m2m (many-to-many) table or a field on the Change Request table to hold a reference to the "parent" Incident. Using field Parent might not be the best choice: it would be appropriate that a parent of a Change Request to also be a Change Request. So perhaps an m2m table would be the best choice. Such tables - as far as I have seen - are excluded from extra license charges - are not considered licensable custom tables (but you'd better make sure that that is the case by contacting your SN rep.) and can be made to behave like the "Group Members" related list on "Group" records: to sport both a "New" and an "Edit..." UI Action that would allow one to designate (and thus associate) any Change as "fixer" of the current Incident.

You can create such m2m tables by typing sys_m2m.list (or sys_m2m.do) into the Navigator Filter and hitting the Enter key:

Or maybe someone else has an OOB solution - let's hope.