there's definitely some truth in there, but you have to understand that the author of that blog post (whom I know by the way, so I say this with <3) is a bit of a... "character". I mean watch her cppcon talk
There Will Be Build Systems: I Configure Your Milkshake to get an idea. Just the first 15 seconds is enough before you're like "wtf is going on here?" Or even just read the title.
What's true is that Microsoft has decided how Modules should be and they're not open for discussion. This is pretty fucked up, honestly, because it goes against the entire spirit of a committee. Once you bring Clang's modules proposal into the picture it starts bordering on... sinister for lack of a better word. One person (who, whaddaya know happens to also be the implementer and designer of Modules on the Microsoft side) is reponsible for editing and controlling the content of the Modules TS. It doesn't take a rocket scientist to figure out that this is a serious conflict of interest when you've got proposals A and B, and the author of A is the gatekeeper to what goes in to the final draft.
The only people that are currently happy with the Modules TS as proposed by Microsoft are the people who don't mind literally re-writing all of their header files from scratch. As you can imagine, that's a ridiculous proposition for people working on existing codebases. or using 3rd party libraries that they can't change. At CppCon a few weeks ago John Lakos (whom you might recognize as the author of the classic book
Large Scale C++ Software Design) got up and asked a question about this, and man was it uncomfortable. You can see a video of the exchange
here (Coincidentally, if you rewind from the time I linked, the previous question is from Isabella, the author of that blog post). It starts out tame but by the end he's completely steamrolling the speaker over these types of issues.
In an ideal world, Microsoft's modules is honestly pretty good. If C++ had no baggage, and you could approach this from a purist language design standpoint, it's probably the right design. It seems like somethign that even, 10-20 years from now, might be good, as we could get there
incrementally. But it completely ignores the practical reality that it's totally unsuitable for retrofitting existing code, and they seem either unwilling to acknowledge that that's a problem, or at the very least unsympathetic with the millions of people who literally will not be able to use modules as a result.
All is not lost though. There's a lot of efforts going on behind the scenes to bridge the gap between the two proposals, and although the level of unwillingness to engage and compromise with the rest of the C++ community on the matter is honestly a little bit unprecedented, at the end of all this there's still going to be a vote, and if the vote doesn't pass (which, in it's current form, it won't), they will look back on this and wish they had been less dismissive of the community's concerns.
Hopefully it doesn't need to come to that, and we can get something good before it ever reaches a vote in the first place. That's still possible, they're just making it much harder than it really should be.