only problem with the fix is that this now throws ArgumentException as listView.Items already contains item and item2 as they were added in the call to listView.Groups.Add(group)

I'm not sure of the best solution as this may be a significant breaking change?

Thinking out loud here.

From a user perspective the following use would likely look logical and expected:

• If an item added to a group, and then the group is added to the listview - all items should have a link to the listview.
• If the group is removed from the listview - all items in the group should no longer have links to the listview.
• If the group (with items) is added to the listview, and then the same item is added to the listview - then the operation is no-op.
• If an item is added to the listview, and the added to the group - no-op, the item is already linked to the listview.
• If an item is added to the group, which is bound to the listivew - the item linked to the listview.
• If an item is removed from the group, which is bound to the listview (i.e. item.Group = null), it remains in the listview.
• If an item is removed from the group, which is not bound to the listview (i.e. item.Group = null), the item must not have a link to the listview. (We should never be in this situation).

I don't have a formed opinion about the following use case though:

• If an item that has a link to listivew1 is then added to listview2 - then it is
  • an IOE? or
  • silent re-assign the link to listview2?

@merriemcgaw @Tanya-Solyanik @JeremyKuhne thoughts?

We might want to consider overloading the API to allow people to opt into what we think is the "better" behavior. So keep the existing behavior without the option...

I think @JeremyKuhne has a great point. We've had the 'bad' behavior long enough that I think people have worked around it and we don't want to break them by default.