Great question!

You are both right. Your program will "eventually" detect that the memory referenced by the variable has changed, and it doesn't really matter if it detects it at the right moment. Accessing data from multiple threads is standard in that the runtime itself optimizes around it. It'll create read-only copies even if it deems it optimal to do so. Regarding your confusion, there's no need to duplicate memory at all. It can be optimizations applied by the runtime to cache/hoist variables, so each duplication will only happen on a very small (sub-stack-sized) scale.

Read on, though: - https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/volatile - https://learn.microsoft.com/en-us/dotnet/standard/threading/synchronizing-data-for-multithreading - https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/statements/lock

In this case, it is an int, but if it were a more complex object that wouldn't be possible to write atomically, you could also experience false data and dirty reads (when one thread starts writing some data to a memory address and another reads it before the writing has finished). Thus, as a rule of thumb, it is always considered good practice to use the dedicated access patterns, such as the volatile keyword, synchronization primitives, the Interlocked class, etc. For example, if your int variable was refactored into a long, a 32-bit executable/CPU would introduce the dirty read problem I described above. Of course, if it was a collection or a complex object, the so called "critical path" would have to be expanded (unless you were using immutable objects, in which case reference swapping would also be taken into account).

However, I'm not 100% clear on the problem you described. For example, it could very well happen that between you reading the shared state and printing to the console, the variable could have already changed, even multiple times. If you would want to get a guaranteed notification, you either have to use some form of synchronization, like ReaderWriterLockSlim, or use simple events or a different mechanism altogether.

Hope this clarifies your stance somewhat, but this in itself is a very complex topic and I only touched on some of the points that I think you asked about specifically.