> Some D users will surely imagine an invariant as a special function, that is implicitly called at the start and
the end of public member functions. For them, implicit nothrow enforcement for invariant may be unacceptable behavior.

That usage of invariants is unacceptable. Maybe they make use of a library which uses contract programming the right way and recieve a giant loss of performance caused by unneeded checks in the library. D has other devices to achieve the same "invariant" effect.

> I don't say that current this change is essentially wrong, but I'm much worried that a built-in language semantics will reject system programming, especially if it requires runtime overhead. We should become very very carefully to add such runtime behavior.

There is no additional runtime overhead in release builds. Can you outline an example where these semantics reject system programming?