I’m having the same problem! Hope so, that someone will find a solution. 

Hey ​@Victor_Sehested and ​@Justyna Ptak — thanks for flagging this and for including those screenshots. I tested this out on my end and can see exactly what you’re describing — this behavior tends to occur when the stroke becomes larger than the shape itself.

I checked in with our engineering team, and I can confirm this is a known issue. We’ve added your reports to the internal project where we’re tracking it. While we don’t have a specific timeline for an improvement yet, here are a couple of solutions:

1. Avoid cases where the stroke width exceeds the shape’s size.
2. Use an ellipse instead, if that fits your design goals.

Also, I have a hunch, though I’d love to hear more about why keeping everything within a single vector matters for your workflow. Any added context on how this is impacting your day-to-day would be super helpful as we continue to share feedback with the product team.

Appreciate you both taking the time to raise this — and we’ll keep an eye out for any other questions that come up!

Thanks for reaching out ​@Tom Reem its greatly appreciated!

Our icon library consist of only stroked icons. To counteract that the icons can be mutiple colors upon color change, we’ve decided to flatten all of our icons to one vector. This has helped us avoid colors on icon instances break. I’ve tried to visualize below what i mean below
 

We’ve kept the icons stroked to have more control over the appearance. Cases could be if we add a new size of icon or want to design a new icon based on our pack, then we have the vector paths easily ready for that.

I appreciate your solutions and have now played around with them, but the use of ellipses seems to have the same issue. Using icons with fill is not possible in our case as explained above. This is also why we wish to keep our “icon color variables” scoped to strokes only. 

If you have any other questions or need more context I’d happily answer everything I can :)

Gladly let me know if you have any other suggestions. We’ve dappled with the idea of isolating our icons in its own library to solve some of the mentioned issues. Right now it is connected to our design system containing components, patterns & templates as well.

 

Thanks so much for following up with those details and your willingness to share, ​@Victor_Sehested.

Totally hear you — these “small” inconsistencies can definitely add up across a file, and I’ve gone ahead and shared this feedback with our product team.

While I’m not able to share a specific timeline for a fix, please know we’re actively working to improve the experience across the board. We’ll circle back here with any updates or solutions that may help.

In the meantime, feel free to reach out if anything else comes up — we’re always here to help.