Earlier quoted context omitted.
Maybe I'm mistaking terminology but that doesn't seem like a type issue you're describing.
There's no one definition of type safety. It ultimately depends on what your type system is trying to enforce. I strongly suspect, however, that most programmers expect "type-safe" languages to enforce memory safety, and that Go's lack of memory safety is surprising in this context.
(sometimes type safety can be proven absolutely by static checking, but you have otherwise only run-time type checking, e.g. dynamic JVM languages, introspection).
Unlimited memory corruption does seem to imply that run-time type guarantees are gone, but it's still better to use the most appropriate terms.