So a condition or comparison does not result in a boolean, it results in a value that can be stored in 1 bit. Its values therefore are 0 and 1. There is nothing to understand, except that the values are dictated by the width of the storage, as usual. The stdbool annotation is cultural, optional, but not C. C does not have boolean values. True and false are mental crutches, names that are somewhat helpful in the absence of an explicit bit type, but still very much a lie.
I think people coming from other languages are driving the future of C now. They are used to booleans as a distinct type, exclusive from other types. Yet in C any int or pointer value has a boolean interface defined on it, and the ambiguous nature of, for for example a timeout, being both a value (time remaining) and a boolean (timed out), highlights the why of C and why C is the king of embedded programming.
So at minimum there are multiple aspects of "booleans" in C that other languages specifically de-emphasize, like storage, representation and the ambiguity of values with other types. The synthesis of the newly introduced C booleans seemingly doesn't take this impedance mismatch into account. From reading it seems there is no synthesis.
Bits have been a traditionally dark corner of C, as I can't declare or index an array of bits; and bit-fields are not my cup of tea (don't use them). I think that's where improvements can be made. Specifically the introduction of a bit type would be in the spirit of C. No need to rename the values, 0 and 1 are more truthful than true and false. If true and false are needed, then a distinct boolean type (as in other languages) might make sense, as an addition, not a replacement. Just to get true/false values and conceptual isolation.
stdbool could not do that and made compromises. Cxx enshrines that compromise, instead of genuinely improving on it. So maybe a bit type for the C programmer and a bool type for everybody else.. :/
Yet C is an impossible ship to turn around, in terms of culture and sunken investments. Changes are virtually impossible and, even more so, highly undesirable. Instead it's time to move on and sunset C. The best C at this point is a sealed C, with a tombstone on it. Then at least it's a known entity, and then C code shall exist side by side with say Rust or Zig code, to be compiled and linked by the same compiler, without language churn. Such systems will proudly carry C into the future. Any C language changes, if needed, should focus exclusively on making that coexistence work.