People seem to make a point of distinguishing between implementation-defined, unspecified, and undefined behavior. What do these mean?

First of all, all three of these represent areas in which the C Standard does not specify exactly what a particular construct, or a program which uses it, must do. This looseness in C's definition is traditional and deliberate: it permits compiler writers to (a) make choices which allow efficient code to be generated by arranging that various constructs are implemented as ``however the hardware does them''
These three variations on ``not precisely defined by the standard'' are defined as:
implementation-defined: The implementation must pick some behavior; it may not fail to compile the program. (The program using the construct is not incorrect.) The choice must be documented. The Standard may specify a set of allowable behaviors from which to choose, or it may impose no particular requirements.
unspecified: Like implementation-defined, except that the choice need not be documented.
undefined: Anything at all can happen; the Standard imposes no requirements. The program may fail to compile, or it may execute incorrectly (either crashing or silently generating incorrect results), or it may fortuitously do exactly what the programmer intended.
Note, too, that since the Standard imposes absolutely no requirements on the behavior of a compiler faced with an instance of undefined behavior, the compiler (more importantly, any generated code) can do absolutely anything. In particular, there is no guarantee that at most the undefined bit of the program will behave badly, and that the rest of the program will perform normally. It's perilous to think that you can tolerate undefined behavior in a program, imagining that its undefinedness can't hurt; the undefined behavior can be more undefined than you think it can.
Since many people seem to have trouble comprehending the depths to which undefined behavor can descend, it is traditional to come up with eye-catching, outrageous examples.
If you're interested in writing portable code, you can ignore the distinctions, as you'll usually want to avoid code that depends on any of the three behaviors.