Why Beacon has more colors now
I replaced Beacon's six-color palette with seven named slots. Counterintuitive simplification — more slots reduced friction, because each color finally meant something.
Beacon's first version of theming had a six-slot color palette. Color 1, Color 2, Color 3, on through to Color 6. Every widget on the page got assigned one of the six. The Now Playing tile used Color 2. The link cards used Color 4. The avatar ring used Color 5. None of the assignments meant anything; they were what I'd picked while building.
This worked until it didn't. Adding a new widget meant choosing one of the six existing colors, often badly — the new tile would inherit whatever Color 3 happened to be, regardless of whether Color 3 was a brand accent or a quiet utility tone. A creator changing Color 3 to fix the new tile would break two other widgets they hadn't realized used it. The slots were nameless and the side effects were everywhere.
I replaced the six arbitrary slots with seven semantic ones: Background, Tile, Text, Brand, Hover, Accent, Avatar. Each has a job. Brand is for primary accents — link badges, focus rings, primary buttons. Hover is for the social-icon hover state (which used to silently fall back to Brand). Accent is the avatar ring, scrollbar thumb, text-selection highlight. Avatar is held in reserve for a future avatar-background feature.
More slots, less friction. The creator picks Background and gets a base color. Picks Brand and gets every primary accent at once. Changing a color now affects the surface the color is named for, and only that surface.
This is the lesson I keep relearning when I look at older work: a flexible system with arbitrary slots is harder to use than a rigid system with named slots. The customization model now matches the creator's actual question, which is never "what should color #3 be" but always "what should the brand color be."