I don't know anything about the .NET Foundation or much about this particular situation, but I know a little about open source governance.

It appears that Novotny believed she was acting in her capacity as a (long-dormant) maintainer of the project when she merged the PR in question. It was clearly wrong to do so without following the process set down by the other maintainers, and she was right to apologise.

However, as the Executive Director of the Foundation, she also had the power (perhaps indirectly) to force a merge of a patch in any project controlled by the Foundation. All Foundations must reserve this power to themselves (you can't take on legal liability for something you have no control over), but they also must never use it. To do so is the nuclear option, to be invoked only after all trust and goodwill has been irretrievably lost anyway, because it certainly will be once you use it.

When you wear multiple hats and one of those hats is very powerful, it is critically important to make clear when you are doing stuff but not wearing that hat. Sometimes even that doesn't help, and it's better to just refrain from doing that stuff until you have handed the hat on to someone else.

In this case she failed to make it clear that she was wearing her maintainer hat and not her ED hat. In fact, she accidentally invited speculation that she was wearing the ED hat by referring to the change as a requirement of the Foundation. I'd imagine this is why things blew up.

Note that this probably indicates a problem with the structure of the Foundation. It's more or less inevitable that at the board level these things are pay-for-play, and that the ED's continued employment is at the discretion of the board. But technical decisions should be delegated to a neutral body, preferably elected by the project maintainers. It doesn't sound like that exists, but had it done this situation might have been avoided.

The other issue seems to be a fundamental disconnect between the Foundation and the maintainers of various projects in it about the purpose of the Foundation. For example, I saw one where a maintainer politely declined to give the Foundation access privileges required to enforce the Code of Conduct, instead saying that the maintainers would enforce it themselves. Sorry, but I don't think any foundation could accept that. One of many reasons for joining a foundation is that it gives contributors confidence that there is a CoC backed up by an independent organisation, and that can be enforced even (especially) against powerful members of the community such as project maintainers - potentially even all of a project's maintainers. This is one of many ways that Foundations help build contributor confidence, which is one of the major benefits for a project of joining a foundation, and all of them rest on the credibility of the foundation to act as a circuit breaker and assert some kind of control should dire circumstances crop up. To allow individual projects - even historically well-behaved ones - to opt out of that control would be to effectively render those guarantees meaningless, and in fact reduce the foundation to what would be effectively just a giant fraud against contributors.

It appears that many projects signed up without being made aware of this, and that is an absolute disaster for which only the Foundation can be responsible, and again they are right to apologise for failing to communicate it. However, what many people wanted was an apology for having technical measures in place that would allow them to exert control over projects, which the Foundation cannot really apologise for because it would effectively be an apology for existing. Inevitably people who wanted that will see this response as a non-apology apology.

It looks like a long, hard road back from here to rebuild trust. I'd suggest that the board needs to work collaboratively with the community to clearly document the rights and responsibilities of both the Foundation and the individual projects, that they consider establishing an independent governance body for technical oversight, and that any project that feels this isn't what they signed up for be given the opportunity to leave on good terms.