Fails to learn from

Introducing breaking changes / branching model

When starting work on a new major version (redesign, bigger change), keep the currently published version on the main branch and start a next branch for the upcoming changes. Developing the upcoming changes on main and use the release/vX branch seems like a good idea, but it's not. For one, the sites in netlify have to be rerouted to fit the above workflow (and then reverted once next becomes stable), also the release process automation is not intended to work in this way. Keep main on the currently published version until you're ready to deploy the next major. Until then, implement breaking changes on a next branch.

Naming implementation layer tokens

Implementation (or component) layer token naming should be reviewed before implementing it according to either Figma or Code. It's not given that the component structure in Figma matches the way the code will be structured which makes it impossible to define shared values for tokens without doing handstands in either implementation. Common agreement should be reached on naming between all implementations that are using these tokens. Also, naming should be as generic and implementation agnostic as possible. Properties for a focus indicator for example differ from Figma to CSS - in Figma borders are called "stroke" and in CSS a "outline" might be used.

Constant re-iterations on the implementation layer create a lot of frustration for everyone involved.