Some might say that the graph is too complex and difficult to maintain.

Some complexity is expected for best performance.

The way ID_RECALC_GEOMETRY_DEFORM skips CoW doesn't seem to be conventional.

Yeah, unfortunately, it is not. We can add non-cow-dependent geometry component, with the operation responsible for ID_RECALC_GEOMETRY_DEFORM in there, and make current geoemtry exit operation dependent on that one. Think it could work!

Maybe it's just me, but I find it a bit confusing that there are nodes that are called "tag xxx". In the scope of the depsgraph, it's the tagging that causes the evaluation, but with these nodes it's the evaluation that causes the tagging. I know that the latter tagging is for the GPU batches and not for the depsgraph, but that's far from obvious when your brain is engaged in "understanding the depsgraph" mode. Maybe it's better to name them after what the effect should be? Like "update gpu batch" or something like that? The fact that that happens via tagging could be seen as an implementation detail.

I'm also in doubt about NodeType::GEOMETRY_NO_COW. For starters, there is no NodeType::GEOMETRY_COW. Furthermore, I'm more in favour of positive naming that express what something is for, rather than what it's not for. Wouldn't NodeType::GEOMETRY_EDIT_MODE be more appropriate?

I don't quite understand the graphs. What do the "start" and "end" nodes represent? Do they mean the same thing in different graphs? I don't know much about geometry batches, so my brain has to work overtime to just follow what's being said. Having to mentally reshuffle the graphs to compare them, as each graph puts things in a different place, makes this process even harder.

Here's a little context of what currently exists (without the patch).

The cut of the graph shown below shows how the depsgraph behaves for updating the GEOMETRY component.
Note that there is no node to "update" (tag dirty) the batch cache.
This is because the BKE_object_batch_cache_dirty_tag is called along with the GEOMETRY_EVAL() operation.
(The only batch cache related node is GEOMETRY_SELECT_UPDATE()).

However, for optimization, we need to do something more granular, and not update the entire batch cache when the geometry has just been deformed.
So we need to remove the BKE_object_batch_cache_dirty_tag from GEOMETRY EVAL() and add another node that only updates part of the batch cache.
So, in the new graph, the component that already has GEOMETRY_SELECT_UPDATE() now has two new nodes: BATCH_UPDATE_DEFORM() and BATCH_UPDATE_ALL(). One node does not depend on the other and are never called together

• BATCH_UPDATE_DEFORM() --> operation BKE_object_data_eval_batch_cache_deform_tag
• BATCH_UPDATE_ALL() --> operation BKE_object_data_eval_batch_cache_dirty_tag

With the patch, if we call DEG_id_tag_update(mesh, ID_RECALC_GEOMETRY_DEFORM), the new node GEOMETRY_EVAL_DEFORM will be triggered and skip the BKE_object_batch_cache_dirty_tag (BATCH_UPDATE_ALL) operation.