Variable library updates can reset theme overrides in consuming files

interesting! to clarify: you had modes (“theme level overrides”) applied to some objects, and after accepting updates from the library where the variable collection is stored, those modes reverted back to the collection's default mode.

Or do you mean: you were using the extended collection feature in your file to make “theme level overrides”, and then after accepting the publication from the original variable collection, your extended collections overrides were lost?

It’s the extended‑collection scenario. I had theme‑level overrides defined in an extended collection, and after accepting updates from the source library, overrides were lost only for the variables I had edited upstream (i.e. temporary scope changes). I’m not sure whether they reverted to the default mode, but this wasn’t an object‑level mode issue. It's like Figma said "something changed with this token so i'm going to set it all back to what the main library is."

Hmm very curious. I will be honest that I haven't found myself in that exact situation, so I can't say one way or the other if that's expected behavior. But generally it seems like Figma respects other types of overrides (like at the component level), so I’d expect the same to be true in your case. I'm going to follow along to see what the answer ends up being. I may try and test this out later too!

Thanks for your post ​@aribirman! And thanks for your replies, too, ​@AlicePackard!

Just to make sure I’ve got a full picture of this, you have a separate, published library that you are using in another file. Within that separate file, you’ve made local components built from instances pulled from that separate published library. When you accept changes to the published library, those changes not only change the local components built on instances of that library, but also instances of those locally built components. Is that right, ​@aribirman?

This sounds like the expected behavior when you accept library changes - it should propagate down including instances of components that are themselves instances of a library component. There is a bit of nuance here where an instance might have a property not be reset (if you have one with a different name from the published library component, for example). 

To clarify, though, is this something new that started happening recently but was different in the past?

Thanks ​@adamsmasher ! I appreciate you jumping in. I think there may be a misunderstanding though. This isn't a component instance override issue. It's specifically about variable overrides in extended collections.

Here's the full setup:

Library file: Contains a variable collection with multiple modes, including a base theme mode.

Consuming file: Uses the extended collections feature to create additional themes that reference the base theme mode from the library as their default. I then manually override specific variable values in the variables table for each new theme.

What triggers the issue: In the library file, I change the scope of a variable (for example, to make a token update), then change the scope back to its original state and publish. When I pull that update into the consuming file, the variable overrides I had set in my extended collections get wiped and revert to the base theme defaults.

Expected behavior: Since I only changed the scope of the variable (not its value), my extended collection overrides should persist.

Actual behavior: Overrides are lost for any variable that was touched upstream, even if the value itself didn't change.

This isn't related to component instances or instance properties, it's happening entirely within the variables table in extended collections.
 

Ahh, ok, ​@aribirman, I see what you mean! You’re specifically looking at the extended collection itself.

I did some digging and see that you have a ticket open about this; I just left a note on your ticket so we’re all on the same page. You should hear back soon from our team, but let me know if you have any other questions!