No, it has real world implications. I worked at a heavy go shop; every time we'd have a new batch of hiring, the segfault bugs would start rolling in from these memory unsafety issues. The data race detector was good, but not perfect. Yes, those new devs would look at you batty until they saw the bug reports roll in.

And yeah, we tend to use the PLT definitions when we're talking about literal semantics of programming languages. Nothing in this thread mandates a security focused sub-definition.

And even Rob Pike described Go as "not purely memory safe", in a slide that obviously references this exact data race behavior. https://go.dev/talks/2012/splash.slide#49 They considered this a practical tradeoff for simplicity versus the major managed languages defining what happens during data races in a way that doesn't allow you to break memory safety.