> Does it advocate good best practices?

That may come down to opinion. For example, type qualifiers are bound to the left.

Traditionally you would write:

    char *var;

They advocate keeping type on the left, name on the right, so:

    char* var;

A few things like that are covered under "Warning to experienced C programmers".

Personally, I prefer it, but have always done what everyone else expects, so there are no fights over styling.

> Does it talk about pitfalls?

Absolutely.

At a glance over, they talk about the unexpected way C treats truthy values (if it ain't 0, it's true), accidentally dereferencing to NULL, and even goes into goto, when it's good, and when it's bad.

> Does it overemphasize new, possibly less widely implemented, features?

Yes. They assume a C11 compiler, and state it in the introduction. At the moment, GCC and clang have some disagreements with how some C11 features should be treated, (GCC accepts a char or a char* for _Generic, clang requires it to be char. clang is more technically correct, but GCC is more flexible), and MSVC is still struggling to implement most of it. [0]

> Does it do/not do anything else we should know about?

I probably need a week to read it more fully, but I'll quote from the end of the introduction:

> Last but not least comes ambition . It discusses my personal ideas for a future development of C. C as it is today has some rough edges and particularities that only have historical justification. I propose possible paths to improve on the lack of general constants, to simplify the memory model, and more generally to improve the modularity of the language. This level is clearly much more specialized than the others, most C programmers can probably live without it, but the curious ones among you could perhaps take up some of the ideas.

[0] https://msdn.microsoft.com/en-us/library/hh567368.aspx

Edit: escaping

Note that var1 and var2 are not the same type:

    char* var1, var2;

Traditional style makes this clear.

> We bind type modifiers and qualifiers to the left.

Good idea in theory but your example shows how bad it behaves in practice.

Usually declare variables one per line, so, type is still clear when:

char* var1;

char var2;

C does not in anyway forbid having two definitions on the same line hence

    char var2, *var1;

is valid C while in Java this would be illegal

    char var2, [] var1;

So the syntax is correct and all you are doing is to add style rules that make it less readable.

Having one var per line, with left bound typing seems more readable to me.

That said, I understand the differences in traditions.

I think that C's syntax is flexible that we can each go to our own, and decide which is more readable.

I tend to see typedef on a pointer type to address this.

    typedef char * pchar;

    pchar var1, var2; // Now they're both pointers

I'm not really a fan, but it can address the problem.

The language is that of Redmont, which I shall not utter here.

And then leave the poor beginner wondering why it's

char var1[10];

and not

char[10] var1;

The rule is simple once you understand it, variables are declared with the same syntax that is used to access it later.