Some quick feedback which should be easy to address.
Seems like a step in the right direction!

I'll look into making these changes 1 comment noted inline.

From the patch description:

Exactly what counts is the perimeter should to be clearly defined.

I think this sentence should also be more clearly defined ;-) I'm guessing you meant "what counts as the parameters".

I don't understand why you are changing DEG_id_tag_update(&me->id, ID_RECALC_GEOMETRY); with DEG_id_tag_update(&me->id, ID_RECALC_COPY_ON_WRITE);

The ID_RECALC_COPY_ON_WRITE is This is most generic tag which should only be used when nothing else matches. So why changes in geometry do not use ID_RECALC_GEOMETRY?

In D11377#299664, @Sergey Sharybin (sergey) wrote:

I don't understand why you are changing DEG_id_tag_update(&me->id, ID_RECALC_GEOMETRY); with DEG_id_tag_update(&me->id, ID_RECALC_COPY_ON_WRITE);

The ID_RECALC_COPY_ON_WRITE is This is most generic tag which should only be used when nothing else matches. So why changes in geometry do not use ID_RECALC_GEOMETRY?

This could be changed, in practice it would work in most cases.

• This patch is meant to be applied before D11337 which changes the behavior of ID_RECALC_GEOMETRY not to do a full COW when in edit-mode.
• When non edit-mode data is modified while in edit-mode, calling ID_RECALC_GEOMETRY will fail to flush the changes to the evaluated data.
• If this can be overlooked (I'm not sure what use-case this would break), then it should at least be documented as a possible problem - as the evaluated data is technically stale, even if this case turns out not to be important at the moment.

This could be changed, in practice it would work in most cases.

Don't quite understand the statement. Maybe you can rephrase it to use less indirections ("this" and "it")

My point was: ID_RECALC_COPY_ON_WRITE is more of an exceptional tag, which should barely ever use, especially when the parameters component properly working. If geometry changed tag with ID_RECALC_GEOMETRY, if parameters changed tag with ID_RECALC_PARAMETERS. If this doesn't work in some cases please write the comment in the code about it, and what is to look for.

Again, mental model is: tag with the flag which corresponds to the changed aspect of the ID.

In D11377#299947, @Sergey Sharybin (sergey) wrote:

This could be changed, in practice it would work in most cases.

Don't quite understand the statement. Maybe you can rephrase it to use less indirections ("this" and "it")

Maybe better to give a hypothetical example of something that could fail.

Exporting a mesh:

- The user has enters edit-mode.
- The user exports the 3D model to a file.
- The exporter runs a validate function on the mesh which happens to call `BKE_mesh_validate_material_indices` internally.
- `BKE_mesh_validate_material_indices` tags `ID_RECALC_GEOMETRY`.
- The exporter triggers a depsgraph update so it can access the evaluated output of data that has been validated.
- `ID_RECALC_GEOMETRY` is handled as it mesh is in edit-mode, the evaluated mesh is left as-is, with invalid material indices.

- The exporter reads the mesh from the depsgraph which has invalid material indices cause an index lookup error, breaking the export entirely.

Even if the example above doesn't fail for some reason, this is an example of the kind of problem that could be caused by using ID_RECALC_GEOMETRY in edit-mode when the evaluated Mesh data is expected to be updated (note that in my testing COW is triggered often which complicates trying to show examples of how removing it can fail).

My point was: ID_RECALC_COPY_ON_WRITE is more of an exceptional tag, which should barely ever use, especially when the parameters component properly working. If geometry changed tag with ID_RECALC_GEOMETRY, if parameters changed tag with ID_RECALC_PARAMETERS. If this doesn't work in some cases please write the comment in the code about it, and what is to look for.

Again, mental model is: tag with the flag which corresponds to the changed aspect of the ID.

It may be we need tags to differentiate between geometry updates that are context sensitive (based on object-mode) and changes to object-data.

What's not clear to me is - do we expect arbitrary data that's modified in an ID to be pushed to the evaluated copy, even if it's not used?

I had the impression we don't want evaluated ID's to be stale, however this means ID_RECALC_GEOMETRY can't be used if it skips the mesh data while in edit-mode.

Thanks for more in-depth explanation :)

We indeed don't want stale information in the CoW domain, as it is a straight way to backfire.

Think easiest solution which is quick to implement is to ad alias ID_RECALC_GEOMETRY_ALL_MODES = ID_RECALC_GEOMETRY | ID_RECALC_COPY_ON_WRITE, and document it something like "Make sure geometry of object and edit modes are both up-to-date in the evaluated datablock. Example usage is when mesh validation modifies the non-edit-mode data, which we want to be copied over to the evaluated datablock." (exact wording surely might need tweaking).

The benefit of this approach would be that things are way more clear for the future-you, so you'll know what exactly is going on, rather than trying to reconstruct a chain of thoughts about "why this generic ID tag was used".

If that's done I think the patch will be good to go.