Typo overriden.

May as well reference the struct member #MPoly.mat_nr.

Reads strangely, could be: \note This for convenient access to the #CD_MVERT layer in #vdata.

... same for similar notes elsewhere in this patch.

Don't think it's correct to say they are "technically redundant"... in some cases they could be redundant - in the sense that the edges could be calculated based on polys+loops.
If we did not support edges that aren't connected to any faces or edge-flags / edge-custom-data.

Perhaps it could be rephrased that edge data is needed to support edges that aren't connected to faces (wire edges) and edge flags & custom-data.

Typo varios.

Worth noting this is #CD_MLOOPUV in #ldata.

Typo convience (elsewhere in this patch too).

This paragraph notes that this is often not used for procedural meshes, but doesn't say when they are used (maybe obvious but could be stated explicitly).

Something like this:

This array represents the selection order when the user manually picks elements in edit-mode,
some tools take advantage of this information.
All elements in this array are expected to be selected, see: #BKE_mesh_mselect_validate which ensures this.

Attempt to make the purpose of this struct-member more clear:

In most cases the last selected element (see #mselect) represents the active element.
For faces we make an exception and store the active face separately so it can be set
even when no faces are selected.

This is done to prevent flickering in the material properties and UV Editor
which base the content they display on the current material which is controlled by the active face.

\note This is mainly stored for use in edit-mode.

Could add: \note Vertex indices should be aligned for this to work usefully.

Worth mentioning:

... in radians, (M_PI` (180 degrees) causes all edges to be smooth).`

re: In the future, this data will be stored as built-in attributes anyway.

Prefer to avoid these kinds of comments, unless they're very explicit, occasionally I stumble over historic comments that state something will be changed/rewritten soon - without giving any details.

If there are plans to do this - is there a task ID this can reference?

This seems a bit vague, For example, parts of the mesh can be asymmetrical.

Attempt to reword this more clearly:

User-defined symmetry flag that cause editing operations to maintain symmetrical geometry.
Supported by operations such as transform and weight-painting.

Don't think this needs to be a TODO, as far as I can see this needs to be kept for versioning (the text could be updated to say so).

Why "historical" ?

Some additional useful information could be added here (or to dw).

• Must not be any duplicates.
• Groups in the array are unordered.
• Indices outside the usable range of groups are ignored.

Worth noting that it typically won't exceed the number vertex groups.