In the About OData APIs section there's a table showing "what you can query", with the first column headed "Query". Might it be worth being more accurate here and using "System Query Option" instead, which is what they are? In this context also, $count is both a system query option, and also used as suffix (also in OData V2).

In addition, in the "OData Service Types and Documentation Requirements" section, the term "OData service" is used to refer to both producers and consumers of OData, err, services. "OData service" is a well-known term and I would suggest that it is confusing to refer to the consumer of an OData service, as an OData service. Perhaps something like "OData producers & consumers and documentation requirements" as a heading might help, with a similar modification for the content of this section?

Feedback doesn't always have to point out issues. I wanted to use this feedback item to say I love that we have this style guide in the open 👍

In this style guide the About REST APIs section talks about how an individual REST API is defined, listing various aspects. A fundamental aspect of REST, namely HATEOAS, is missing from the list. While HATEOAS is a constraint normally found only in APIs that have attained RMM level 3 and many pragmatic RESTful APIs exist without implementing that constraint, don't you think that we should at least mention the Richardson Maturity Model and include a fundamental aspect of REST in this list, rather than exclude it (see https://www.youtube.com/watch?v=bhn-Dl87SDE for background)?