However, I'm still not a big fan of languages where values exist that are automatically crashes if you try to touch them in some bad way. Why are they there, then? My mental image is one of the anthropomorphized language just tossing caltrops around willy-nilly and blaming people who get stabbed for not being careful where they walk. I think it's important to call this idea out separately because programmers should learn this principle as they learn how to use strong typing systems: Do your best to exclude meaningless states for which your only recourse will be to crash if you see one from your system at the type level. The C-style NULL value is a degenerate case of this general principle.
Yes, this absolutely includes Go. I consider it a mistake in any language. In particular I'd highlight the distinction between reading a nil map (legal, gets the zero value of the value type for the map) and writing to one ("kablooie") as particularly bothersome and asymmetric, especially in light of the way nil slices can often be "written" to (via append which is in practice much more common than using index access to write) legally. Lots of asymmetries around what actually blows up vs. what "works" (but quite likely isn't doing what you want) in Go here. I'm not really in love with getting zero values out of a map if the key doesn't exist anyhow and I tend to pretend that only the check for both the value and existence exists in my own code (because I almost always care about existence too), but I especially don't like that behavior out of nil maps.
NULL pointers and undefined behavior make a lot of sense in C++. The mistake is replicating this behavior on languages where it doesn't.
Not at all. The C standard doesn't allow pointers to take arbitrary numerical values; while you can cast back and forth, the only guarantee is that casting a pointer to a numeric value and back to a pointer still points to the original object (and even then only if the numeric type used is large enough, which couldn't be portably ensured prior to C99, and is only conditionally supported even now).
In particular, one thing that the standard does not guarantee - and there have been implementations that did not do so - is that casting a null pointer to int will produce zero, or that casting int zero to a pointer will produce null. Nor does it guarantee that a null pointer is an all-bits-zero value.
The fact that you can write "p = 0" in C is not because pointers can take arbitrary numerical values, but because the language syntax and semantics allow you to do so, with 0 being treated specially when assigned to an lvalue of a pointer type. But you can't write "p = 1", for example, because there's no such special treatment for any other integer literal.
If it's two mistakes, it's one big one (having null pointers at all) and one tiny one (the fact that calling methods on null pointers is undefined behavior in C++). The latter is yet another C++ gotcha, but not nearly as pernicious as the former, which causes nearly all the null pointer-related bugs in the wild.