My Studio Tweaks plugin attempts to do smarter reselection like this, however the algorithm isn’t perfect yet (is missing recursive behavior), and is definitely sub-optimal because the selection Studio generates on undo does not contain any instances that are not parts or models (e.g. Folders). This results in needing to jump through a lot of expensive algorithmic hoops to go from the list of reselected instances on undo, to a list of highest common ancestors including containers such as Folders and Scripts (which makes sense to select instead, since the draggers will move all children of a selected instance just the same as a model).
Even in my algorithm’s imperfect state however, it is significantly more tolerable, which you can see in this below example. The problem happens when Studio begins trying to update the explorer, but if you intercept the selection immediately on undo and clear it to an empty table, the problem does not happen (which my plugin also lets you do).
i.e. If all children of a parent that are parts/models or contain part/model descendants will be reselected, do not select those children and select the parent instead. Start from the very bottom of the instance tree, and do this recursively until the highest common ancestors are found. This rule is is significantly better than the current behavior, and should result in the draggers affecting the parts you’d expect them to affect after undoing. Most often, when you delete some parts and then undo, you either plan to deselect right away, or you plan to continue manipulating them with the draggers, so since the draggers still affect only the parts you’d currently expect after undoing, this is most likely fine.
I imagine performance doing this will be better than my plugin if it can be done with C++ rather than Lua. This functionality really shouldn’t need to be provided by a plugin. Studio should seek highest common ancestors when undoing a delete.
My plugin’s behavior using the above rule:
The default behavior: