I'm confused; it seems like you're saying that clipV1.getLinkedItems() and clipV2.getLinkedItems() return correct results...?
More than 'linked', are you trying to determine clipV2's "ancestry" (from where it was duplicated)?
Could you describe the desired behavior, from the user's perspective?
I think effectively what I'm saying is that a trackItem seems to have no unique identifier.
When stepping through a sequence programatically one can confer a unique identity to each trackItem by referencing the item's track group, track number and clip number ... but there is nothing within a trackItem itself that is necessarily unique.
As such, getLinkedItems() only tells me that the returned trackItems collectively make up all instances of a "linked clip" ... but that collection includes nothing that uniquely identifies where in the active sequence those clips are located. I can make a best guess by looking for any other trackItem that returns a matching "linked clip" collection ... but if duplicate linked items exist in the same sequence at the same start /end time (but on different tracks) then there seems to be no way for me to differentiate which items belong in which linked collection, as they will all appear to match.
I guess from a users perspective, the simplest behaviour would be for every trackItem to have it's own unique identifier property, regardless of links and/or ancestry. The function getLinkedItems() could then continue to work as is, but the unique identifier inherent in the trackItems returned would allow a user to discern specifically which trackItems belong in which linked group. Alternatively, a trackItem could include a trackNumber property. Again, getLinkedItems() could continue to work as is, but the track number property, together with the existing properties, would allow a user to discern the unique identity of each trackItem.
And another possibility is that I'm just missing something entirely obvious!