For example two consumers pushing results to a single result queue is a race condition, because the order in which they arrive depends on timing and is non-deterministic. That's a pretty normal thing to have.
Many languages people think of as being safe and high level are extremely racey - Erlang is my go-to example - two processes sending messages to a third is a race. Which message do you get first? It's non-deterministic. But it doesn't have to be a problem.
That's what a race condition is - non-deterministic behavior of a thread-safe primitive.
> On the other hand, a true race condition in the queue could mean messages overwriting each other.
That's a data race, not a race condition.
And many race conditions don't have anything to do with the memory model or compiler optimizations.
For example, poorly structured response-handlers in JavaScript. If the code assumes that request R1 always returns before request R2, things may misbehave if that assumption is violated. That's a race condition, but as you say, it's nothing to do with memory models or compiler trickery, as JavaScript gives you just the one thread (not counting workers).
That's not correct. Look at chrisseaton's definition.
If the observable program behaviour doesn't change depending on the order in which the requests complete, there's no race condition. (In JavaScript this might be done with Promise.all.) You're right that not all race conditions are bugs.
Can you give an example of when one would (sanely) want to create a race condition?
The average developer assessment that some race condition is completely harmless is wrong; there's usually a bug in the complicated state space somewhere.
A performance optimization involving a deliberate race condition should be pretty much your last resort.
Even the obvious ones are often less of a good idea than they may look, like a leaky incrementing counter for logging purposes. You might model that as being unlikely to lose more than a couple of percent, but I've seen cases where it lost the majority of logged events. Granted, this probably won't crash your program, but it can still result in surprisingly deceptive logging.