This has already been stated by others, but I just wanted to pile on - I agree with Walter's definition of assert.

2. Semantic change.
The proposal changes the meaning of assert(), which will result in breaking existing code.  Regardless of philosophizing about whether or not the code was "already broken" according to some definition of assert, the fact is that shipping programs that worked perfectly well before may no longer work after this change.
 

Disagree.
Assert (as I always understood it) means 'this must be true, or my program is broken.'  In -release builds the explicit explosion on a triggered assert is skipped, but any code after a non-true assert is, by definition, broken.  And by broken I mean the fundamental constraints of the program are violated, and so all bets are off on it working properly.
A shipping program that 'worked perfectly well' but has unfulfilled asserts is broken - either the asserts are not actually true constraints, or the broken path just hasn't been hit yet.

Looking at the 'breaking' example:

assert(x!=1);
if (x==1) {
 ...
}

If the if is optimized out, this will change from existing behaviour.  But it is also obviously (to me at least) broken code already.  The assert says that x cannot be 1 at this point in the program, if it ever is then there is an error in the program.... and then it continues as if the program were still valid.  If x could be one, then the assert is invalid here.  And this code will already behave differently between -release and non-release builds, which is another kind of broken.


3a. An alternate statement of the proposal is literally "in release mode, assert expressions introduce undefined behavior into your code in if the expression is false".

This statement seems fundamentally true to me of asserts already, regardless of whether they are used for optimizations.  If your assert fails, and you have turned off 'blow up on assert' then your program is in an undefined state.  It is not that the assert introduces the undefined behaviour, it is that the assert makes plain an expectation of the code and if that expectation is false the code will have undefined behaviour.



3b. Since assert is such a widely used feature (with the original semantics, "more asserts never hurt"), the proposal will inject a massive amount of undefined behavior into existing code bases, greatly increasing the probability of experiencing problems related to undefined behavior.

I actually disagree with the 'more asserts never hurt' statement.  Exactly because asserts get compiled out in release builds, I do not find them very useful/desirable.  If they worked as optimization hints I might actually use them more.

And there will be no injection of undefined behaviour - the undefined behaviour is already there if the asserted constraints are not valid.
 

 Maybe if the yea side was consulted, they might easily agree to an alternative way of achieving the improved optimization goal, such as creating a new function that has the proposed semantics.

Prior to this (incredibly long) discussion, I was not aware people had a different interpretation of assert.  To me, this 'new semantics' is precisely what I always thought assert was, and the proposal is just leveraging it for some additional optimizations.  So from my standpoint, adding a new function would make sense to support this 'existing' behaviour that others seem to rely on - assert is fine as is, if the definition of 'is' is what I think it is.