(In reply to Thomas Lendo from comment #0)
> Suggestion 1:
> 
> Imported palettes should be handled like the custom palette with means to
> modify, remove and rename colors.

You would need to override the previous custom colors or to merge the two lists. Both likely not wanted.
 
> Suggestion 2:
> 
> It should be possible to pick the custom color palette file and imported
> color palette files within a file manager in the user profile to copy, to
> edit it by hand or to rename it.

Don't get it, and it sounds strange.

The enhancement request is a clear WONTFIX for me. Color palettes are one mean to handle a list of colors. You still have the document colors, the ordinary color picker, own custom colors etc. 
There is no use case to make palette handling as easy as possible, and when we add more options here it's feature-creep. Even the (IMHO more obvious) solution #3, to define at the palette itself whether it is read-only or not, makes no sense as it adds complexity (it's not the checkbox, or the like, that is complex but all reasoning behind we do in this and other tickets that average users are not aware of). People who want to go into detail should rather hack the file.

> Where are custom and imported color palettes stored now...

Predefined palettes are placed at <LibO>/share/palette, the user palettes in <user>/libreoffice/4/user/extensions/+, the custom palette is stored in <user>/libreoffice/4/user/registrymodifications.xcu.

(In reply to Heiko Tietze from comment #1)
> (In reply to Thomas Lendo from comment #0)
> > Suggestion 1:
> > Imported palettes should be handled like the custom palette with means to
> > modify, remove and rename colors.
> 
> You would need to override the previous custom colors or to merge the two
> lists. Both likely not wanted.
Accepted if not wanted. But I mean neither an override nor a merge. Imported palettes should be handled like custom palettes but should still be separate palettes. (Don't know how the palette management is implemented now, in a user's POV it only needs a "edit-possible" or "handled-like-custom" flag set to the imported palettes. :-) ) Example:

------------------------------
| imported palette           |   <--- edit possible
| imported palette           |   <--- edit possible
| custom palette             |   <--- edit possible
| LibO breeze palette        |   <--- no edit possible
| LibO xyz palette           |   <--- no edit possible
| LibO standard palette      |   <--- no edit possible
------------------------------

With that others can also improve/edit palettes and it's not stuck(!) to the first and original editor and export user of the palette.
(Use case if user edits the imported palette unwantedly: 1) Users fear changes, so this isn't a problem that I see. 2) If a user did a change, it can be undone by re-importing the extension palette easily.)

> > Suggestion 2:
> > It should be possible to pick the custom color palette file and imported
> > color palette files within a file manager in the user profile to copy, to
> > edit it by hand or to rename it.
> 
> Don't get it, and it sounds strange.
What I meant is if the custom palette were saved as a separate .soc file in the user's profile, you could take the imported extension palette .soc file from user\uno_packages\cache\uno_packages\lu123 and you could copy that file to the place where the custom palette would be saved. Then you could rename both so that the new .soc file (and not the original custom palette .soc file) is handled like the custom palette in LibreOffice.

But as you said, the custom palette is now part of the registrymodifications.xcu (and no separate .soc file anymore) which makes it extraordinarily difficult to handle this use case.

> There is no use case to make palette handling as easy as possible, and when
> we add more options here it's feature-creep. Even the (IMHO more obvious)
> solution #3, to define at the palette itself whether it is read-only or not,
> makes no sense as it adds complexity (it's not the checkbox, or the like,
> that is complex but all reasoning behind we do in this and other tickets
> that average users are not aware of). People who want to go into detail
> should rather hack the file.
I explained the use case above and in the initial bug comment.
I don't want any new options. The user should have nothing to do. It should just be possible to edit imported palettes like custom palettes. Maybe if it's not wanted then a flag in the Expert Configuration could be set.

Nothing changed.
Version: 6.4.0.0.alpha0+ (x64)
Build-ID: 41cd3e8e817c8c33a13608e62eeb06ce2c6977e4
CPU-Threads: 12; BS: Windows 10.0; UI-Render: GL; VCL: win; 
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-09-01_22:04:10
Gebietsschema: de-AT (de_AT); UI-Sprache: de-DE

Imported palettes are like templates or gallery items some static piece of artwork. There is no point of editing the Breeze colors, for example, and if it belongs to the maintainer. So clearly a NAB (actually WF) to me.