This is a wish list of improvements for the GradientPicker component (& related components) that I came up with while fixing popover regressions:

Slow rendering performance

This can be observed especially when dragging a control point in the editor:

Improve the initial state when there's no gradient set

• The semi-transparency given to the whole gradient bar is weird, especially when clicking on an insertion point: in that case, the popover is also semi transparent, and is rendered below the rest of the controls (this is a side-effect caused by the opacity rule, which creates a new stacking context for the gradient bar)
• I also find it weird that the "no gradient set" state is represented by the value of the gradient being set to the default one — in my mind, that value should be undefined (or null), but definitely not a gradient. The visual state of the component should be also adjusted to clearly show that there's no gradient being set

Done as part of #49146

Get rid of __experimentalHasMultipleOrigins prop

We should agree on the best way to implement this feature, and remove the experimental prop. I'm personally not a fan of props like __experimentalHasMultipleOrigins that change the meaning of other props (in this case, gradients). Maybe we don't need __experimentalHasMultipleOrigins at all, and we can just infer the information from the shape of the gradients prop

Done in #46315

Get rid of the __experimentalIsRenderedInSidebar prop

We should avoid props that introduce a tight coupling with the editor. First we should understand exactly what changes when this prop is specified, and then find alternatives to get to the same results

Component structure is messy

We should tidy up components and folder structures for the GradientPicker-related components (GradientPicker, CustomGradientPicker, ColorPalette, ColorListPicker, CircularOptionPicker, ColorIndicator....). These components feel very intertwined / tightly coupled and partially overlapping. (related to #35093 )

Sometimes clicking on the GradientPicker in the editor doesn't result in a new control point being added

I can't reproduce this unexpected behavior consistently, but it's definetly something that we should investigate (it could be related to the low rendering performance listed above)

Done as part of #49146