Нужен ли пустой палитре отдельный вариант?

Maybe [Color] даёт то же различие без третьего случая. Nothing означает свежую правку, Just [] означает палитру, которую намеренно опустошили, и второго способа записать пустоту, который пришлось бы запрещать, просто нет.

Проще всего, по-моему, начать с Save. Свежая правка, ничего не введено, Save недоступна. После Clear сохранить пустую палитру можно. Добавили синий, убрали синий, и сохранять всё ещё можно, ведь пользователь этот выбор уже сделал.

Когда это решено, для создания хватит одного правила. Пустой список становится Empty, непустой становится Colors, и код редактора строит состояние только через эту функцию. Colors [] перестаёт появляться на обычном пути, и для этого не понадобился целый тип непустой коллекции.

Палитрами, загруженными извне редактора, займёмся потом. Проверяйте их до того, как они станут состоянием приложения. Имена вариантов этого за вас не сделают.

Дыру с Colors [] можно закрыть при создании. В Java это sealed interface Palette permits NotEntered, Empty, Colors, где NotEntered и Empty это записи без компонентов, а у record Colors(List<Color> values) компактный конструктор бросает исключение на пустом списке и сохраняет List.copyOf(values).

Тогда удаление последнего цвета обязано дать Empty, потому что Colors пустым существовать отказывается. switch по Palette с шаблонами записей тоже проверяется на полноту, так что четвёртое состояние, добавленное позже, сломает каждый исчерпывающий switch, где его нет. Вариант со списком и флагом ничего из этого не получает.

Но Just [] это та самая дыра, на которую указал oskar91. В Elm я бы написала type Palette = NotEntered | Empty | Colors Color (List Color), один обязательный цвет и остальные. Палитра с цветами не может быть пустой по построению, а если в case забыта ветка Empty, компилятор назовёт недостающий шаблон по имени. Честно говоря, это сообщение об ошибке и есть половина причины, почему мне нравится такая кодировка.