The palette selection button is at the bottom, which makes for an awkward popup, especially if the palette docker is bottom-most. I would like to move this to the top of the docker and make the click are larger and the name of the palette more prominent.

I agree with this.

I am not sure whether the new/import/export/delete palette buttons really are best placed in the popup, maybe they should be moved into the top of the palette docker?

Personally I think it might make some sense to keep these on the bottom side.

Because then it'd split the UI so that the stuff of the top is used for selecting a palette, while the stuff on the bottom would be for editing the current palette.

I also find the current order of the buttons to be a little bit weird. Maybe we could push Add/Edit/Remove to the bottom-left, while Edit/Save could be pushed to the bottom-right?

I would like to replace both with a common dialog: it should be possible to set the number number of columns and creating groups when creating a new palette, too.

Totally.

For editing a single color swatch, it's not clear what the swatch ID is supposed to mean:

As someone who rarely uses the Palette Docker, I guess because I've never loved the experience, I find both the Add Color and Edit Color dialogs confusing.

Like you point out, I'm not sure what the significance of ID is--changing it doesn't seem to change how the colors are arranged or anything, so it's not an index.
On top of that, I don't know what Spot Color does. I'm vaguely familiar with the concept, but I can't say I understand what it does or why I would use it, and I'm probably not the only one.

Also, right now none of these widgets have tooltips, so that doesn't help.

zoomable -- right now the size of the swatches is dependent on the number of columns
fixed number of columns
fixed number of rows

I haven't completely thought it through yet, but It might be nice to have 2 modes, Dynamic and Static, configurable per palette.

There are some cases where the palette is designed around a fixed number of rows and columns, and in that case a Static mode where the users specifies the layout is what we want.

But in other cases you might just have a simple set of colors that aren't logically arranged in any particular way, and in that case a Dynamic mode (where the palette is dynamically arranged to best fit the space) might be preferable.

A little bit of flexibility would go a long way towards making better use of the available UI space, and it'd look a lot better in some circumstances too:

Wish: generate palette from the image

I'd love this, especially if we could tune it so that we could ask for the top-N colors from the source image.

One other thing, I'm not sure how I feel about the current palette auto-saving when Krita is closed, especially given the lack of undo/redo support.

I just nuked half of my default palette by messing with the number of rows per group, couldn't undo the change, then tried to restore it by restarting Krita, only to figure out it saved automatically.
If it happened to me it'll likely happen to someone else too.

I know that the obvious alternative is someone making/customizing a palette and then forgetting to save the changes, which is also bad, but we should probably look for a better way.

Undo/Redo has already been implemented, it's just not visible in the merge request I made for it because to work properly it needs to remove the KisPaletteEditor class.

I'm still thinking that having the buttons that work on palette files on top with the selector, and the buttons that change a single palette file on bottom might be a good idea.