I thought the same thing, but I did some digging and color is generated in ThreadSettings where it is initialized to threadInfo.color (as colorEditValue):

So they are initialized to the same value. However, throughout ThreadSettings, colorEditValue is updated to match changes made to the state. For example:

So colorEditValue and threadInfo.color seem to be the same, but colorEditValue gets updated more...but the only thing that is confusing is in the old ColorPicker the defaultColor prop (color) takes precedence over the oldColor prop (threadInfo.color), which is a fallback if color is undefined:

To me, the variable naming is not clear. defaultColor sounds like the color that should be set if the user has never changed the thread color, ever. oldColor sounds like the "current" color that will only become "old" if the user decides to change the color. But then threadInfo.color would also be updated, which is the original value of oldColor.

That's why the new ColorSelector only takes one prop: currentColor. By the reasoning above, I went with color instead of threadInfo.color as currentColor which gets passed into ColorSelector. I tested both threadInfo.color and color as the prop that get passed into ColorSelector, testing new thread creation and all and they both seemed to work the same.