I’m happy with the current slogan wording simply because the precise technical meaning of “guarantee thread safety” is more or less “concurrent code cannot cause memory corruption without opting in to special unsafe/FFI powers”, and I’m not aware of any stronger notion of “thread safety” that any practical language has ever attempted to provide.
Obviously no language can claim to categorically prevent logic bugs in concurrent code, and pretty much every non-systems languages like Python and Javascript and whatever has some unsafe/FFI features that could trivially subvert their usual safety guarantees. What Rust, Python, Javascript, et al can all reasonably claim is that you never have to think about thread safety in those languages until you explicitly opt-in to unsafe/FFI stuff, and you never need to think about concurrent logic bugs until you explicitly write some concurrent code. That is not the case in C++ and Java, where every class you define must be written and documented with concurrency in mind (even if only to state that it’s one of the trivial cases like all fields being final/const), or else nobody can ever safely use the class in a multithreaded scenario without going back and fixing it. And even in these languages, when a class’ documentation states that it is “thread safe”, that also usually means any client code using it (that does not itself opt in to unsafe/FFI stuff) cannot cause memory corruption.
I do think there’s a legitimate, interesting question of whether the term “thread safety” is intrinsically misleading, but that’s a question for the broader programming community, not Rust specifically. Rust’s slogan seems to be using what is in my experience the typical established meaning of that phrase, and slogans are not the place to challenge a term’s established usage.