For consistency with function names and comments, perhaps use attribute instead of layer?

So:

struct SculptAttributeParams
struct SculptAttribute
struct SculptAttributePointers

I think the organization of members in this struct can be better:

/* Domain, data type and name */
eAttrDomain domain;
eCustomDataType proptype;
char name[MAX_CUSTOMDATA_LAYER_NAME];

/* Source layer on mesh/bmesh, if any. */
struct CustomDataLayer *layer;

/* Data stored as flat array. */
void *data;
int elem_size, elem_num;
bool data_for_bmesh; /* Temporary data store as array outside of bmesh. */

/* Data stored per BMesh element. */
int bmesh_cd_offset;

/* Sculpt usage */
SculptLayerParams params;
bool used;

int -> eCustomDataType

Seems redundant with layer != NULL?

I'd rename this to for_bmesh, my initial guess is that this was somehow data stored on bmesh.

Add comment explaining what used means in this context.

There's a convention being made for attribute names in T97452: Attribute identification and semantics. Perhaps use:

.sculpt_persistent_position
.sculpt_persistent_normal
.sculpt_persistent_factor

Or perhaps it should be like this, constructed with the SCULPT_LAYER_NAME macro below?

.sculpt.persistent_position

Cusotm -> Custom

Rename scl -> attributes for clarity? Or something less obscure at least.

This could be internal to paint.c instead of in the public API.

If it's public, it's not clear when this kind of updated is expected to be done and should get a more detailed comment.

These two functions could get more consistent names, perhaps like this:

BKE_sculpt_attributes_destroy_temporary_mode()
BKE_sculpt_attributes_destroy_temporary_stroke()

It's unclear why this is updating only a subset of SculptAttrPointers. Why this specific subset? Is there a generic function needed to update that struct?

This seems to rely on the assumption that if no PBVH exist, the type can't be a PBVH_GRIDS.

It's not obvious that this is true, or will true after future changes that are unlikely to take this assumption into account.

Can this actually happen, and what are the consequences then?

Or should this have BLI_assert() or BLI_assert_unreachable() and be a fatal error?

Can this workaround be replaced with CustomData_sizeof?

Assigning domain and proptype here is redundant.

Same comment as before, can this go through BKE_sculpt_attribute_ensure and the whole sculpt attribute system, or should this remain an exception?

It's now used for this, so remove comment?

These 3 attribute pointers don't seem to be used.

This still didn't explain why specifically persistent_* attributes need this and not others. Is it because they're the only ones with a lifetime longer than a stroke? If so add a comment explaining that.

If it can happen in practice then it should be handled gracefully instead of BLI_assert_unreachable.

I don't think this is correct for all PBVH types, while BKE_sculptsession_get_totvert gives different results for each. Not sure if it matters in practice, but seems logical to have this consistent.

Ok, if the purpose is to keep the pointers valid on changes I guess it's fine as is.

Make static

Make static.

Should this be const SculptAttributeParams? sculpt_attribute_create seems to modify params while sculptsession_bmesh_add_layers uses the same params variable for two different attributes. I would not expect params to be modified here so would try to at least make it const in the public API.