Great, I love someone that is willing to get their hands dirty hahaha!
The presence/absence of a color picker for a color selection is determined by the boolean argument in the color selection constructor $Init::col_sel. If you unzip the sprite styles and look into manifest.tds, search for occurrences of “$Init.col_sel(” to find all the color selection constructors. The ones defined to NOT have color pickers will have a false argument. Set this to true and they will have a color picker.
I don’t exactly remember how every single color replacement is defined off the top of my head, but for Puny Characters, for example, it actually performs color replacements by loading image files from the palettes subdirectory and sampling pixels at certain coordinates of that image. The color choice is represented by rows, and the specific color in the ramp (highlights, neutral, shadow) is represented by the column. Because of this implementation choice, adding a color picker won’t produce the desired effect and may lead to runtime errors/crashes. In that particular case, you would have to rewrite all of the color replacement logic to make it work with the color picker.
The general rule of thumb I used to adapt sprite styles for collaborations like Time Elements and Puny Characters is that if the artists were intentional about color palettes, I define color replacement logic and color selections in an enumerable way. You would have to write custom replacement logic for skin tone for Time Elements as well, for example.
Feel free to check out the sprite style development guide or read through the API specification for a better understanding of the theory. I can give you more detailed one-on-one help if you email me at jordanbunkework@gmail.com.
And thank you so much!