No, implementation defined means the standard said, This is allowed, but we do not specify what will happen. That's up to the compiler to decide. Undefined means This is not allowed. All bets are off.

The problem is that programmers probably assume that many things which are undefined are implementation defined.

An example of something that is implementation defined are struct layouts: the standard (I think) does say that the order must be the same as defined in the struct definition, but it allows the implementation to put as much space as it wants inbetween those values (for optimal architecture alignment.) Things that are implementation defined are typically going to be things which must happen, but if the standard defined exactly how, it would unnecessarily constrain the implementation (such as being able to perform optimizations).

That's not what that means. If a program has undefined behavior that means the program is allowed to do anything. If a program has implementation - defined behavior that means the compiler writer must decide a behavior and document it.

Those aren't different. The idea is entirely that "implementation defined" is vague enough to allow definitions such as "do whatever it takes to simulate the undefined behavior as never even having occurred". That opens up new optimization techniques as shown.

"Implementation defined" means that the compiler can do whatever it feels like, but that it must choose something specific and that this must be documented, and any program that invokes implementation defined behavior is perfectly well formed. "Undefined" means that the compiler can do whatever it feels like and it can be completely inconsistent and documented nowhere, and any program which invokes it is ill-formed, and programs can be assumed not to invoke it.