To sum the link behind that statement up: The default output format used by the GNU Compiler is for GNU Make, a ninja compatible format can be generated but is not the default. The blog author considers this default broken, GNU developers consider this behavior correct.
The suggested flag was not for a "ninja compatible format", but to exclude things from the makefile snippet that ninja doesn't understand (yet). It would exclude necessary information for modules to function.
Problem is, the new syntax used by the compiler's -MF output violates current-day expectations by both compilers and build tools as to what those snippets contain, and it'll be a while to sort out what the acceptable syntax would be. As noted, Clang doesn't use this file to propagate the information at all.
> gcc (and other compilers like clang) support emitting dependency information in the syntax of a Makefile.
But didn't quite make it to the second paragraph:
> (Ninja only supports the limited subset of the Makefile syntax emitted by compilers.)
Obviously Ninja can't parse and execute full Makefile syntax because then it would just be Make. But the actual information in depfiles doesn't require the full Makefile syntax; only a subset of it. And compilers output that subset, so Ninja can read it.
The issue is it's a de facto subset - a "depfile syntax" that exists by convention but the GNU authors have broken this format. As I said, unless there's a good reason to break it, that's just shitty behaviour.
That seems to be the problem, the information introduced for the module support[1] apparently cannot be handled with just the dependency lists alone and the changes suggested in the ticket would still leave the additional CXX_IMPORTS += M1.c++m syntax. One of the commenters on the ticket also wrote a specification for a json based dependency format[2].
[1]https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p16...
[2]https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p16...
My point is that I wouldn't jump to conclusions as to why they did that. I would dig further to see what the reasons were (which is not a simple google search) and what Ninja developers could do about that.
Another important point is that they didn't break Ninja compatibility in general, but only in the specific case of C++ modules; and they also didn't break compatibility with non-GNU implementations of Make.