I think that the spec is essentially weasel words keeping the implementer's options open for the future - it's a difficult area where you really don't want to h

I think that the spec is essentially weasel words keeping the implementer's options open for the future - it's a difficult area where you really don't want to have to throw unreasonable numbers of gates at the problem, and because you (as a chip architect) really don't know what sort of issues you might run into 10 years from now you keep your options open. Existing implementations may be tighter, but as a programmer if you want your code to run reliably in the future you should follow the declared rules. An example from elsewhere: RISC-V has an instruction that you execute between when you write the data to memory and when you execute the changed code. How it's implemented is up to the chip architect (this rather puts the shoe on a different foot architecturally) - at a worst case you have to: 1) flush the data to memory, 2) flush the instructions caches, 3) flush the execution queue .... a system with a good cache coherency setup might minimise this with: 1) flush the write queue to L1 data cache (as a side effect cache coherency flushes just the required instruction cache entries rather than the whole cache) 2) flush the execution queue - still not exactly lightweight, but you're likely going to pull those new instructions from the companion L1 data cache