Problem

WT_PAGE_MODIFY (src/include/btmem.h:365) mixes two naming prefixes for fields that all track per-page eviction/reconciliation history, and __split_multi_inmem_mod_stats_update() (src/btree/bt_split.c:1450) copies all of them together, which makes the inconsistency obvious:

/* The transaction state last time eviction was attempted. */
uint64_t last_evict_pass_gen;
uint64_t last_eviction_id;
wt_timestamp_t last_eviction_timestamp;
...
/* The largest transaction and timestamp seen on the page by reconciliation. */
uint64_t rec_max_txn;
wt_timestamp_t rec_max_timestamp;
...
wt_timestamp_t rec_pinned_stable_timestamp;
...
wt_timestamp_t rec_prune_timestamp;

• last_evict_pass_gen, last_eviction_id, last_eviction_timestamp use a last_ prefix.
• rec_max_txn, rec_max_timestamp, rec_pinned_stable_timestamp, rec_prune_timestamp use a rec_ prefix.

Both groups record state from the most recent eviction/reconciliation attempt on the page (per the comments at btmem.h:369 and btmem.h:383), but the naming doesn't signal that they're closely related, which makes call sites like __split_multi_inmem_mod_stats_update (bt_split.c:1450, copying both groups field-by-field) harder to scan.

Proposal

Standardize on a single prefix convention for these fields (e.g. all rec_, or another consistent scheme), updating all declarations in WT_PAGE_MODIFY and their usages throughout the tree. Note last_evict_pass_gen/last_eviction_id/last_eviction_timestamp record the state as of the last attempted eviction (whether or not it succeeded), while the rec_ fields record values from the most recent *successful reconciliation — preserve that semantic distinction in whatever naming is chosen (e.g. rec_last_evict_pass_gen vs rec_max_txn), don't just blindly rename.

Low risk, mechanical cleanup — no behavior change.