True. The indeterminism provided by letting the OS and cache coherence reorder thread execution and memory accesses in response to external factors is one of the reasons parallel execution can provide speedups in practice, so benign races are important to permit.

But this is a data race: the mail program performs a check on some data (in the filesystem) to establish some precondition, and then a concurrent thread of execution (another process) mutates that data before the mail program acts on its (now invalidated) belief.

LLVM wouldn't call it a data race, because to LLVM all system calls are essentially opaque. But if the filesystem only existed within your process, and were written in idiomatic Rust style, using structs, borrowing, mutability, and lifetimes, then the analogous bug (two threads racing and mutating the filesystem at once) would be prevented. The real villain here is shared mutable state; if UNIX had been written by skilled Rust progammers, it would with any luck have some abstraction that provides more isolation and less potential for interference than the filesystem.

> if UNIX had been written by skilled Rust progammers, it would with any luck have some abstraction that provides more isolation and less potential for interference than the filesystem.

I think this is kind of absurd and my guess is you haven't worked on a filesystem driver. At a certain point there is value in admitting that race conditions are a part of the universe and developing strategies to deal with them, rather than waste a bunch of overhead trying to isolate a program from the real world or from itself. The semantics you seem to want would be really crazy for a filesystem.

  > on some data (in the filesystem) 

Traditionally, "data race" only refers to memory, not other forms of resources. So I agree with you that this is like a data race, but would dispute that it's actually a data race.