A summary of how gpd_dst is used would be useful, even after reading the code it's not so clear what the intention is with this exactly.

The destination is read from but may be NULL, in that case a zeroed struct is used.

The doc-string should elaborate on the purpose of passing in an existing destination which may be used as a copy & why a caller want to pass this in.

bGPdata *BKE_gpencil_data_duplicate(Main *bmain, const bGPdata *gpd_src, const bGPdata *gpd_dst_reference).

This way the API reads better (returning a duplicate instead of writing to a pointer argument), and it's clear the gpd_dst_reference is an argument that can be used to initialize the destination struct.

Should be gpd_src matching the implementation.

Missing doc-strings.

This function isn't defined anywhere.

Clang-tidy will remove the else added in this patch, same for the else below as they both have returns in the previous blocks.

Logically using the existing <= comparison seems correct. When the flags are equal the current cache should cover the new cache.

Since I assume there is a good reason for this change it should be noted why equal flags can't be used.

is a no copy reads poorly could be written as: is a "no-copy" to make it clear this isn't poor grammar. The same could be done for for `"full-copy" although this doesn't read as badly.

Also use capitals and full-stops.

Worth noting in this doxy-gen section which object-modes the undo system is used for.

Prefer scene_frame or scene_cfra (to make it clear this value is from the scene, not a value from the grease pencil which is the default assumption for undo data storage).

Prefer object_mode, otherwise this reads as if there are different undo-modes (without first looking at the declaration).

Is there any reason this needs to be allocated?

In most cases it's simpler not to, avoiding the additional pointer indirection, allocation & freeing.

It might even make more sense not to have two separate structs and make UndoStep step; the first member of GPencilUndoData.

Either way, if it's important to allocate this as a separate pointer and explanation for why should be noted here (if they were shared between undo-steps for example).

Otherwise it can either be changed not to be a pointer or the structs merged.

No need for else as previous block returns.

No need for else as previous block returns.

No need for else as previous block returns.

Prefer:

ViewLayer *view_layer = CTX_data_view_layer(C);
Object *ob = OBACT(view_layer);

As undo is low-level and should use pointer lookups that can't be overridden by Python or the current editor.

ID_RECALC_ALL is checked in this function - is the comment still valid? Would rather not leave comments like this unresolved.

Or, at the very least expand on the possible user-visible down side of this being left as-is.

Returning false should be an exceptional case, if undo data could not be created because of an internal error for example (if the active object isn't found or there is some unexpected context where it's impossible to encode the undo data) ... where failing to create an undo-step is preferred over crashing.

This is because of user muscle memory, if you perform 3x editing-actions, you would expect undoing 3x times to restore this state - anything else should be avoided unless there are no alternatives.

If the undo step is effectively empty / no-op, that's OK, although in general most user actions should not be a no-op.

Typo happened.

Use OBACT macro, see comment above.

ID_RECALC_AUDIO_MUTE seems an odd tag to use, shouldn't ID_RECALC_FRAME_CHANGE be used instead?

If not, a comment explaining why mute is used instead of frame-change (or tag both, also with a comment explaining why).

The logic for gpencil_undosys_step_decode seems like it could be simplified, firstly undo has much more involved logic than redo - which seems strange as they are similar operations.

The use of next/previous here also seems error prone. I'd prefer these undo steps work more like image_undo.c see: image_undosys_step_decode.

Where each undo step uses the is_applied member, seeking forwards/backwards, checking the undo-step type and the value of is_applied depending on undo/redo. As far as I can see something close to this logic can be applied here.

prefix multi-line comment blocks with *.