If you need it to be a group, that will mean copying or moving the art into a single group (I recommend copying if you want to leave the document as it was when you're done!). If that's the case, just create a kGroupArt somewhere and then start iterating your list of handles using AIArtSuite::DuplicateArt() or AIArtSuite::ReorderArt(). Do your optimizing and kill

One thing to be aware of w.r.t. the matching art array -- it may do something that some of the other mass 'get selected art' functions do. The AIArtSuite's GetSelectedArt() call will get you a handle to a compound path AND each of its children. So if you had only a compound path with two sub-paths in a document and the compound was selected, you'd get three handles back: the compound parent and the two sub-paths. That means if you copied all three you'd double up the two sub-paths and they might not be rendered correctly (since they likely inherit properties like stroke & fill from their parent). There's an attribute you can test for, kArtPartOfCompound, to sort this problem out with the help of AIArtSuite::GetArtUserAttr().

What's not working? I think there's a flag you can set in the MatchingArt function that will ignore those duplicate objects. Or you could try using the ArtSet union functions to eliminate extra handles.

The duplication only comes into play if you have compound paths, so its easy enough to test. The trick is you could easily have compound paths that DO cause duplication and still not see an artifact visually. You could still see some in other cases though. I think one that would be a good example is a donut: take two squares, one inside the other and compound them. If you get no duplicates, you'll just get the donut and it will obviously look okay. If you do get duplicates, you'll get the compound, with its two paths inside when you copy, but also the two paths separately. If you have a fill (e.g. black) then you'd probably get both squares as filled black -- and since they're not a compound, they'd just appear on top of one another, providing what would seem to be just a large black square (as opposed to one with a hole in it). The test, as I said earlier, is fairly easy if you do see this problem: just ask the art before you copy it if it has the kArtPartOfCompound attribute. Again, this is assuming you actually have the problem

Also, and this is another consideration I just thought of: is Z-order preserved? Maybe you've tested this, but you might try layering three coloured boxes and making sure they get rendered correctly. One would assume that the array of art handles would be in the order they were encountered, but you never know. Well, you don't know until you test it, which you may have already done

Yeah, I think we basically test for kArtPartOfCompound and skip it, knowing we'll handle the parent. Obviously if you want to do something with compound children, you'd handle it

Z-order is trickier, but I think you'll get the selected art in top-to-bottom order. Either that, or the reverse