If you set the Item to an IEnumerable, the control strips away all the Attributes of the source properties. For example, the DisplayNameAttribute, or the DescriptionAttribute (all of them). So, what you get is with one item, you see the display names of properties as declared in the class, but then if you supply a List of 2 items, all the display names are shown as the original property name. Kind of odd.
To further confirm, if I hook onto the AutoGeneratingPropertyDefinition event, and I want to add logic like suppress a property if it has the MergableProperty(false) attribute, well, I can't, because the PropertyDefinition.SourceProperty.Descriptor you supply has no Attributes. The collection is empty. You've supplanted the original PropertyDescriptor with a PropertySetPropertyDescriptor that has stripped away much useful information.
Luckily, I can work around all of these problems by matching up property names with the original PropertyDescriptors for the given type, and then fixing up the property definitions, but I don't know, I think you can do this a lot better.
Also, it seems necessary to have to switch the PropertySetMode between 'None' and 1 of the other choices when going from single item to multiple items. Why? Why can't the logic be smart enough to say, if Item is not an IEnumerable, then do single item properties, else if multiple items, then do multi-item logic. The property should not need to change. Changing PropertySetMode causes an internal Refresh, so we must set Item to null first. There are other quirky behaviors I've noticed when going to and from single-item mode and multi-item mode, like with the CategoryAttribute, it can stick in the UI when in Grouped mode, even though the Category heading should disappear, but I'll wait to see what you say to all of this.