OK will do

If people create dependencies on their bone shape objects, then those should be overridden, there is nothing wrong here.

If this includes the bone shape objects themselves, then this contradicts the explicit removal of tagging, right? Also: "custom_shape" should not be PROPOVERRIDE_NO_COMPARISON then, right?

Not sure why custom shape object needs to be parented to anything? That does not look like the right thing to do to me in a decent rig, would expect those bone shape objects to remain isolated in a hidden sub-collection or something like that...

Just checked, and indeed when we mark asset it become a fake user, so why need to store all trash data? - unclear.

Asset Browser allows you to simply view some data, and that's it, its presence cannot affect the saving of unused data in the file.

As I understood it's because with new Asset Browser we need to store for example unused material with it nodes and not be purged after close blender.

I think it's like turning an automatic transmission into a manual.
The manual purge solution is familiar from the Autodesk family of products and all of their longstanding problems.

The relation is to the parent (in the example file, the custom bone shape Widget is parented to Wgt_grp -- and the bug only occurs if Widget is actually parented, without parenting, this is fine)
So an MainIDRelationsEntry is created for that, with its i`d_pointer.to` set to Wgt_grp.
Happens from BKE_main_relations_create / object_foreach_id / BKE_LIB_FOREACHID_PROCESS(data, object->parent and there seems nothing wrong with that.

This whole proposal looks strange. It looks like you are trying to design a part of the engine without considering the whole engine.

What would be interesting is to know what relation causes that re-tagging ?

will check

Thanks for the patch, but this cannot be a proper solution, if the bone shape object is added back in the override set by lib_override_hierarchy_dependencies_recursive_tag, it's that it actually needs to be overridden to satisfy other relationships.

Can confirm, will have a quick look.

See add_loose_object_data_to_scene in readfile.c

Think we are once again suffering from the embedded ID plague... My guess would be, when we check if a linked Object is used somewhere, we forget to check for usages from master collections of scenes...

Havent checked code, but this is not expected behavior, right @Bastien Montagne (mont29)?

Can confirm that adding a DEG_id_tag_update_ex(bmain, &ob->id, ID_RECALC_TRANSFORM | ID_RECALC_GEOMETRY | ID_RECALC_ANIMATION); to rna_Main_objects_new also fixes the issue, think all those RNA new ID functions should do some recalc tagging in fact?

Note that BKE_object_add_only_object (which is called from RNA object creation) does not set any recalc flag, while higher-level functions like BKE_object_add_for_data (which gets called from Editor code, including operators, when creating a new object) does flag new object with ID_RECALC_TRANSFORM | ID_RECALC_GEOMETRY | ID_RECALC_ANIMATION...

Think this is an update flag issue... But am still trying to figure out what exactly is going on here, this is fairly weird. Could also be a missing bit in depsgraph update?

An Undo modal/dialog could help. Its "Tagged Undo" subsystem/layer/tree/table could use time-stamps and context tags to distinguish undo actions. This way, for example, Text Editor events wouldn't have to be undone just so that 3D-View actions can be undone, even if they took place about the same time. Not all undoable actions show up in the Info area, so for this implementation, 'Alt+z' would display a dialog of user input events, listed by tag (context) columns, with check boxes in each action cell and for each individual context-based event group.

@Bastien Montagne (mont29), the builder frees IDs which are no longer in the depsgraph, so this is kind of expected I think.

In my case the curve turns flat gray:

@Sergey Sharybin (sergey) or @Sybren A. Stüvel (sybren) may have an insight here? Looks like`DEG_graph_relations_update` builds then frees some data that is later being accessed by draw code?

Another interesting ASAN crash report:

I personally do think that const-correctness is important, especially if we want to port our code base to C++. If we don't have const-correctness in these lower level functions, we won't get it in the higher level ones. I think the overhead of just a little function is neglectable.

In T85752#1115246, @Philipp Oeser (lichtwerk) wrote:

you can also enable it again here! Very unexpected!

Why is this so unexpected?

you can also enable it again here! Very unexpected!

Not sure if we should enter collection_object_cache_fill a second time at all?
After all the LayerCollection is excluded, but not familiar enough with the mechanisms that sync flags between Collections and LayerCollections (or whether they should be checked here)
If we enter a second time, child collection related memory is garbled

Makes me wonder why this has not been reported before, but yes, can confirm, will check on this.

@Germano Cavalcante (mano-wii): sorry for not checking code here.

What's happening is that the thumbnail now displays the material in solid preview mode.
I suspect that behavior has changed with rBb219ae4498ef: Fix T79077: Off-screen rendering ignores shading argument, which is a fix and therefore the expected behavior is the current one and not the previous one.
This seems to be confirmed in the blend_file_thumb function which has OB_SOLID as the draw_type.

Note that the thumbnail is updated every time the file is saved. A workbench-style thumbnail only takes a second or two, while one with materials and textures could take a very long time... every time you hit "save". So there is some tradeoff here between quality and time. I did some experimenting with using random object colors and found them to be good previews that were very fast to create: https://developer.blender.org/D9404

Just a note that in Blender 2.81 it made the rendered thumbnail when there was no camera, but now it doesn't anymore.

This task should be split up into smaller more specific tasks.