I think this could cause subtle changes in behavior.
Timer is triggered early in the time step, before processes are run, and doing the writes at that time might change behavior, but I haven't looked at the event models in a while.

I wouldn't be against adding a setting that lets users switch to your proposed behavior.

Timer is triggered early in the time step, before processes are run

So this would mean that writes applied by cocotb would be applied after the Timer callback and before the processes run, allowing them to be "seen" by processes? That would be less than ideal. IMO cocotb tasks should be treated as more or less parallel to processes in HDLs.

But applying writes at the beginning of the ReadWrite stage means that cocotb tasks that operate directly after those writes in that ReadWrite stage aren't operating on the outcome of processes or cocotb tasks that applied writes in the previous "pseudo process execution" cycle.

It seems there should be the following behavior.

1. Run HDL processes
2. Run cocotb "normal" stage
3. Apply non-blocking/signal writes from stage 1.
4. Apply .value signal writes from stage 2.
5. Run cocotb ReadWrite stage. Repeat from 3.
6. Run cocotb ReadOnly stage.
7. Progress simulation time to next time step. Repeat from 1.

The order of 1 and 2 shouldn't matter (it will matter, but we can't guarantee anything. Just don't depend on forced or blocking/variable assigned objects). 3 doesn't matter the order of cocotb or HDL (well, same as before).

Is there any way to accomplish this with the timing model available to all the procedural interfaces?