(NB: this constructor has not yet been released to the world, so renaming is still OK.)

Renaming is fine regardless, it causes a bit of churn, but I don't think it's worse than, say, adding locations to the ast, which happens regularly.

I'm not fond of Texp_letitem. For example this name is easily confused with Texp_let: imagine a new code reader that hasn't looked the documentation yet, what would they guess about the difference between Texp_let, Texp_letop and Texp_letitem? (Personally my guess would be that let x1 = e1 and x2 = e2 in body has two "let items", x1 = e1 and x2 = e2).

Texp_struct_item is fairly unambiguous because there are few things that structure items can do in an expression. But if you would like to emphasize the concrete syntax, I think that Texp_let_struct_item and Texp_let_stritem would both be better than Texp_letitem.

I expect that the name would be understandable just fine in context. But I guess Pexp_letsomething is still better than the current name (ideally, using the most common shorthand for structure item, because it's annoying when each api randomly chooses between str vs stri vs struct_item vs structure_item, or pattern vs pat, or expression vs expr vs exp or typ vs ty etc).

But IMO, it would just be simpler to fold Pexp_let into Pexp_letitem anyway. Less invariants, more similarly between similar constructs this way.

Discussed further in today's triage meeting. All in all, there was no consensus in favour of this renaming, and some developers were in favour of the current name. Closing then due to lack of agreement.