> 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).

If R2 returns before R1 that is still a race condition, but it might not be a bug.

> If R2 returns before R1 that is still a race condition

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.

There is even Promise.race provided for that purpose in JavaScript. You can typically use it to implement a watchdog.

Particularly if they are done on purpose???

Can you give an example of when one would (sanely) want to create a race condition?

I don’t think you ever want a race condition for the sake of it but there are many daily cases where you don’t care that it races and fixing it would have terrible downsides. In a distributed system they’re practically unavoidable I think!