Dumb ungrouping algorithm?

Besides duplications Group/Ungroup.

Lets say I Group/Ungroup Gain & Stones component is kept as is.

Now, lets say I Group/Ungroup Color Control & Stones.
Gain changes into a Curve Control? (they operate differently)

Quote
Besides duplications Group/Ungroup.

Could you give more information on these duplications?

Regarding the problem at hand: this "feature" is a byproduct of our current ungrouping algorithm which is pretty dumb. When ungrouping, it just dumps controls outside the group (apparently without preserving any settings) and restores their connections exactly as they were inside the group.

This obviously isn't an optimal solution, especially for cases when the group has incoming connections from other components. Ideally, such connections should be maintained after ungrouping, not replaced with dangling control components.

However, this is a delicate matter. For example, if we chose to "maintain incoming connections after ungrouping", what do we do with the control components? If we restore the incoming connection, it will go from the originating component to the input directly, bypassing the control component. Should we delete the control component? Or just dump it somewhere nearby, unconnected?

Also, it's not always possible to maintain incoming connections after ungrouping. This is easier for Maps and Curves, but can be problematic for Numerics (gray) due to the extraneous remappers: a numeric connection to the group can have a remapper AND, inside the group, connections from the corresponding control can all have their own remappers. Basically we have two remappers between the originating output and grouped component, and during ungrouping we'll have to somehow collapse them into one.

P.S. I renamed the thread. The new name sounds a bit harsh, but I believe it will attract more viewers.