Purpose of clocking blocks in SystemVerilog, how do they help mitigate race condition

About signals in a testbench the books "SystemVeril" states that "Drive too late or sample too early, and your testbench is off a cycle. Even within a single time slot (for example, everything that happens at time 100ns), mixing design and testbench events can cause a race condition, such as when a signal is both read and written at the same time"

I know that in a testbench we drive signals onto the input of DUT. We already know the output we expect as a result of these inputs. Then we merely assert that the actual output is equal to the expected output at a specific duration into every clock cycle. I am not sure when we would actually end up reading and writing a signal at the same time. When can this happen in a testbench?

Later it states about clocking block that "You can specify a clock skew in the clocking block using the default statement, but the default behavior is that input signals are sampled just before the design executes, and the outputs are driven back into the design during the current time slot."

What does it mean by "..outputs are driven back into the design during the current time slot"?

Finally a side question about clocking blocks is about this "Clocking blocks are mainly used by testbenches but also allow you to create abstract synchronous models."

What are abstract synchronous models? :bang:

Thanks