I don't think you understand the status quo. I wasn't trying to express advice that "Everyone should suppress nodiscardness at every turn."  I was simply expressing the actual fact that, if you want to suppress nodiscardness, then you should use (void). (Or a project-specific macro that expands to something like that.)

Obviously if your project has a coding guideline that states "Thou shalt not suppress nodiscardness," then, corollary, thou shalt not use (void) casts, either.  (And this is great, because `(void)` is easily greppable.  Analogously, many projects state "Thou shalt not use raw owning pointers," corollary, thou shalt not use `new T` either; and people grep for `new` and `delete` to verify that.)

For more on the messy state of [[nodiscard]]-suppression, see

(It uses the result, so yes, it causes any warnings triggered by non-use not to be emitted. This isn't what I mean by "suppression," though.)

Okay.

You still seem to be operating under the misapprehension that a programmer might write either

    auto x = f();

or

    auto _ = f();

when what they actually meant to write was

    (void)f();

and then you would let that mistake through code review. My advice to you (both) is: Don't.

Furthermore, if you have a rule that "Thou shalt never ignore the result of a [[nodiscard]] function," then you should actually be code-reviewing to make sure that results of [[nodiscard]] functions are always used. If, during code review, you see someone writing

    [[nodiscard]] int f();

    (void)f();  // X

    auto x = f(); (void)x;  // X

    [[maybe_unused]] auto x = f();  // X

    std::ignore = std::make_tuple(f());  // X

    []{}(f());  // X

etc. etc., you should flag the lines marked `X` in code review and tell them, "Hey, we have a rule here that you're never supposed to suppress [[nodiscard]]ness! Go fix this code!"

Complaining about the C++26 semantics of `_` doesn't seem productive to that end at all.

Arthur