It absolutely would be a race condition, and you would need to assure correct behavior with synchronization at the level of code. However, this coherence protocol would assure that any subsequent reads make sense, meaning that you can't do two simultaneous reads and get different values.

If CPU-2 modifies the data then it will invalidate the data with CPU-1, so CPU-1 will be fetching the data from CPU-2 cache.

If a cache entry enters an Invalid State, then its contents will never be written back to memory. A cache line enters an Invalid state when the shared data is written/modified within another cache. So, the cache contents that eventually get written back to memory will come from a Modified or Shared cache line that corresponds to the same one that was Invalidated in some other cache.

At 1:34 I say that the caches are snooping on signals sent by the caches to each other, and these signals are indeed sent on the bus, but I suppose I could have been more precise with my language. As for whether or not MESI or snoopy protocols in general are any good is an issue you need to take up with computer engineers. The point of this video is to explain a protocol that is used in actual multicore systems. However, if by dev you mean the person writing user programs, then they most definitely should not be responsible for the contents of caches. Cache contents are meant to be invisible/transparent to the programmer in most cases, since user programs work at the level of memory, not the cache (though there are a few exceptional commands that allow for some cache manipulation, and these have led to some scary back channel exploits).

@@JacobSchrum No, that one scenario of which to write SHOULD be the devs problem as it's THEIR data it effects, should be caught via the signal handler with something like SIGCLASH, then the dev can check what clashed and decide which to keep or whether to abandon them complety, as far as they're concerned it's still normal memory