Tagging and forcing an update for something what is needed 5 levels deeper in the callstack does not sound correct at all.

The sculpt pointer is supposed to be used from the original object, as it is the source of truth. So the fact that evaluated object points to a possible outdated one is weird.
I guess this is caused by mesh_get_eval_final which actually re-evaluates the object, which is wrong on its own. Why is it re-evaluating the object? Should the depsgraph be "acquired" from the context by CTX_data_ensure_evaluated_depsgraph(C), leaving away the need of BKE_object_free_derived_caches and mesh_get_eval_final ?

In D9270#229254, @Sergey Sharybin (sergey) wrote:

Tagging and forcing an update for something what is needed 5 levels deeper in the callstack does not sound correct at all.

The sculpt pointer is supposed to be used from the original object, as it is the source of truth. So the fact that evaluated object points to a possible outdated one is weird.
I guess this is caused by mesh_get_eval_final which actually re-evaluates the object, which is wrong on its own.

Yes that's also what I thought (just don't have enough experience in that area to be sure that that was actually bad).

Why is it re-evaluating the object? Should the depsgraph be "acquired" from the context by CTX_data_ensure_evaluated_depsgraph(C), leaving away the need of BKE_object_free_derived_caches and mesh_get_eval_final ?

But this code gets called from many different places, so will take some time to check whether we can actually use BKE_object_get_evaluated_mesh all the time, or if we need to handle both cases.
Another problem is that ED_object_sculptmode_enter_ex gets called from within undo code of sculpt, don't think we can expect having an evaluated depsgraph from there.

Currently non-fully-formalized rule of thumb is to do ensure_evaluated at the top level, and pass evaluated depsgraph. The function must be clear whether it expects things to be evaluated or not. The reason for this is to avoid re-evaluations o nthe "bottom" levels when, say, operator does modify a lot of objects. So general flow is such:

• An operator ensures depsgraph is evaluated in the beginning, which gives all the input data for it to operate on
• Operator modifies data, tags for update

This is a bit of a sidetracking, but I think it is good to state this to ensure the understanding of what and how is expected to be is same on our both sides.

The ED_object_sculptmode_enter_ex is called from called from sculpt_undosys_step_decode, which does ensure the depsgraph is evaluated. So the depsgraph is evaluated, unless undo system sues some other code pass which is not immediately clear to me.

Maybe proper approach would be to:

• Replace mesh_get_eval_final with BKE_object_get_evaluated_mesh
• Remove the BKE_object_free_derived_caches call
• Track top level calls where depsgraph pointer is passed, and make sure it is evaluated

Maybe also add DEG_id_assert_evaluated() macro in DEG_debug.h, which will assert that the given ID is fully evaluated. Could help tracking cases when the object which is moving into the sculpt mode is not yet evaluated.