Badge > 12px and 16px icon Figma variants behave the same way

# Issue

Following on from the changes in #1280+

Badges with 16px icons retain their icon overrides when changing variation.

Badges with 12px icons do not retain their icon overrides when changing variation.

| Behaviour (16px) | Behaviour (12px) |
| ------ | ------ |
| ![Kapture_2022-03-30_at_11.45.21](/uploads/afd07cf52d0cadefca2d28095909dc60/Kapture_2022-03-30_at_11.45.21.gif) | ![Kapture_2022-03-30_at_11.47.10](/uploads/76a448e35ccffb43c6bd7818bebf8035/Kapture_2022-03-30_at_11.47.10.gif) |

# Proposal

Make 12px and 16px icon Figma variants behave the same way.

As discussed in the Figma branch for #1280 there are some tradeoffs to be aware of:

- Lose a 'sensible' default

### [Figma branch for review :eyes:](https://www.figma.com/file/xIqrqxGgcl50I8akiQzfmG/%231281-badge-12px-and-16px-icon-override-parity?node-id=19947%3A350)

<details><summary>Full conversation:</summary>

Hey Jeremy Elder Nadia Sotnikova 

here's a little bug fix for the 12px icon variants to fix
- Colour persistence when changing icon
- Icon persistence when changing variant

This makes the 12px icon behaviour the same as the 16px icon behaviour.

However, it does come with some tradeoffs
- Lose the 'sensible default' icon for each status

wdyt?

Changes:
- base components: Rename icon symbol layers
- base components: Relink icons to icon library
- variant components: Update to use naming from base component
- variant components: use the same icon to allow icon change persistence

---

Dan MH "Lose the 'sensible default' icon for each status" might be a dealbreaker for me. These have specific icon/color relationships that should exist out of the box.

---

Jeremy Elder I respect and understand that.

I found this unexpected behaviour when trying to add a badge to the Single Stat - https://www.figma.com/file/17NxNEMa7i28Is8sMetO2H/Data-Visualization?node-id=383%3A72

It is a pretty high friction process in its current form. And the defaults aren't sensible here.
To clarify — my expectation was for these to follow the same persistence rules as 16px icons.

The good news is, I'm 90% sure there is an alternative way we can set these up:
- Icon swaps use the right colour
- Variant (colour) swaps change the icon to the icon defined in the variant. 

---

Dan MH would you be good with me updating this branch to the latest? It'll include the new tier badge.

---

Jeremy Elder I'd prefer to do it so I can remember what the changes were see_no_evil emoji

But only if we think we will proceed with any of these updates?

Otherwise we can just delete the branch

---

>But only if we think we will proceed with any of these updates?

I think it's a valid proposal if you're 90% sure it can be done!
Applied changes from main, so it may have reset the icons here.

---

To confirm the desired/proposed behaviour:

- 12px icon badges come bundled with an icon
- Icon changes maintain the correct colour to match the badge pill
- Changing the colour variant changes the icon to the bundled icon

If I'm tying myself in knots trying to explain I can jump on a quick sync at some point

Ok thats all done, and I think it is an improvement as is. :) 

However, for many of my use cases the 'sensible defaults' hinder rather than help — so it would be nice to consider changing this behaviour to match the 16px icons in the future!

---

Dan MH after some consideration, I don't know that it's helpful to be as prescriptive here.

I had to circle back and through about the ability for you to extend these for your use case, but then that indeed would mean overriding this use case, but this use case is prescriptive and not universal, which isn't what we're going for here. Follow?

So… I'm up for reworking these to use generic defaults that can be updated at the time of use.

What could be helpful, would be adding out instances of the different color/icon/size associations commonly found. Thoughts?

---

Thanks for the continued discussion here Jeremy Elder .

Honestly I do see both sides of it.

My workaround was going to be to create extension of these (and other) symbols that match Optimizes use case and maintain them in an Optimize library.

I don't know what is best for the system and its users. Happy to follow your lead here.

I do think merging as-is would be an improvement, perhaps we could open this conversation wider for the last bit?

---

Dan MH Figma is having a tough go at spelling out what the changes are that I'm approving, could you unpack it a little further in the review description when you have a moment?

---

Jeremy Elder I've documented it in this issue https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/1280

I wasn't expecting this much discussion, otherwise I would have created it sooner :D 
</details>

Story points: 1.0