I think we are seeing it from different perspectives, and the reasoning i gave is that it should be consistent with other operations on groups. IE the you work on the group, not on the item.
a) If you only wanted to work on one item, then you can always pick it from the explorer. Not the group. Or create a group of that one item.
Example, if you have three items in a group, a sphere, a torus, a cube, then you deform by lattice, you dont deform only a subset of the items in the group, you deform the whole group. And thats exactly the correct logic. And all other operations on groups work the same. Exactly the same thing is true if your using physx, cloth etc.
Now, if you want to deform only one item eg a subset of the group see a)
That’s why if you take the point position from a group, it (if we are logically assuming the same workflow as other group operations) only makes sense to return all the points. (just like that lattice does when deforming !?)
Further to that, different operation of different things, depending on operation chosen means the integration of items with each other eg ice with lattices with dynamics with envelopes with cloth with deformers with physx etc become a convoluted problem, because you have inconsistent data selection, that’s not only a workflow problem for the user, but for the developers.
I think the most important thing is to look at it context of all the other operations that can be done on group, and their workflow, reasonably they should all operate in the same manner, this means users don’t get frustrated. From the development point of view, knowing that, means that at any point you ‘know’ what to expect from a function call to a group (development wise), wrt what data you were getting back, irrespective of ice/lattices etc, which would make the integration of all (and any new) items on the list above one hell of a lot easier, because you know what to expect in return irrespective of what was operating on the group and less prone to bugs, or limiting them to the new operations that your creating, not core system functionality. This way it becomes a case of making the new operation fit the existing system, not the other way around, which then will and does inevitably lead to bugs cropping up in new versions, that didn’t happen in older ones.
Either way Zen, but I dont think SI will make any change, any time soon, so in some ways both of our comments are moot. But its been a interesting conversation.