I'm not the one who claimed it was modular & gave a bunch of nonsense examples & happen to agree with maxperson's summary of what was being discussed
before thesword lept in. That agreement is why I linked to it in the post you quoted. The goalposts didn't shift, they were drawn out & debated over before his entry.
as to your dotnet example you don't include enough detail to comment on. Lets say you wrote a dotnet CRM application with no ability to send out gather process an/or ackowledge email is a need other than then allowing customer email addresses to be recorded then claimed not every company needs email functionality so a company who does expect it in a CRM could just write a subsystem for that very basic expectation of CRM software, you'd get less than positive responses because companies who don't & you'd get those responses because companies who don't want email in their CRM could just turn off that component.
Failure to include basic things like functional tactical combat system that can just be ignored by groups who don't want to worry about things like a robust system for things like AoOs/facing/flanking/etc could just turn that off by not using those rules. Just like that email processing/managing capability in a CRM you can trivially turn those things off by simply not using those rules but can't simply drop it in because it touches too many things.
@Bolares this & other recent threads went into detail about why may of those optional/variant rules are incomplete & lacking. If you order a steak & it comes out raw or vastly undercooked "but there is a baked potato too" doesn't change the fact that the chef left out a key component of making a steak even if you didn't want the potato. If you get a perfectly (or even reasonably decently) cooked steak and a baked potato you don't want it's easy to ignore the potato because you wanted the steak.