[intro.memory] has a note that says "It is not safe to concurrently update two bit-fields in the same struct if all fields between them are also bit-fields of nonzero width." The term fields is not defined in the standard.

[support.srcloc.class.general] has a comment saying "source location field access" which is novel in the library clauses. We could say "access functions" or "member access" or just get rid of the comment. It has very little value. Either way, I don't think it needs to include "source location" in that comment or the one above the constructors. We know which class we're looking at.

[mem.res.pool.options] says "specified in this field" twice, which should be member.

[time.cal.ymd.overview] and adjacent subclauses uses "field-based time point" which I think means the mathematical meaning of the word, i.e. a set that supports arithmetic. It's arguable if this actually helps.

[time.hms.overview] says "The individual duration fields always return non-negative durations". I'm not sure what this means. It seems to be referring to the non-static data members h, m, and s (which have types that are specializations of duration) but what does it mean for them to "return" something? Does it mean the corresponding member functions? This could be improved.

All uses of "field" in iostreams, locales, and std::format are OK, it's talking about widths and padding of text fields, which seems fine. This isn't confusing, and matches the use of "field" in ISO C.

[diff.cpp20.utilities] says "bit fields" which should be hyphenated.

[diff.dcl] refers to "field initializers" which isn't defined in ISO C or ISO C++.