假如两边确实指向同一个任务，我们仍要问：它们各自在什么时候读到了这条任务？
“现在显示在屏幕上”描述的是显示动作发生的时刻。它不自动说明数据刚刚产生，也不说明这份结果比先前那份更新。
一次读取至少经过：取得状态、响应到达、页面显示。三者之间可能隔着等待和其他操作。
本实验用同一范围里的递增版本帮助核对状态变化，用读取编号关联一次读取的证据。版本只在同一范围内可比，不是整个世界共用的时间。
服务端的 S 序号说明本次服务现场记录的先后；浏览器的 C 序号说明那个浏览器观察到的先后。两个浏览器各有一个 C1，不表示这两个动作发生在同一时刻。真正能把线索接起来的是读取编号、捕获版本与各自的先后关系。
登记预测，然后读取服务器时间线。找出准备起始画面时，右侧取得快照和任务变为完成的顺序；这些记录标记为 scene-setup。
若右侧先取得旧状态，随后任务才改变，那么起始画面的差异可以得到一个时间上的解释。继续核对对象线，确认版本属于同一范围；再核对显示线，确认页面确实显示了它收到的数值。
若右侧取得的已经是新版本，这条时间解释就不够。不要因为本课标题讨论“过去”，就强迫所有现场都成为旧数据问题。
实验台提供可控调度，操作时会明确把同一任务设为未完成，再完成：
先不启用“按查询范围与版本验收响应”，预测最后屏幕会保留哪份结果。开始实验后，在 40 秒内放行；超时会明确报错，不把超时当作旧数据已成功显示。
这里真的有两个响应在不同时间返回，但等待是实验装置有意控制的，不能把它的具体延迟当成真实互联网的分布规律。
从记录中找到同一 request_id 的 S 捕获、S 发送、C 收到、C 显示。先写出“旧读先捕获，新读先到，旧读后到”的关系，再解释页面如何选择结果。
如果页面每次收到响应就覆盖显示，那么较旧消息也能成为最后可见的那份。最后到达描述的是传递顺序，最新描述的是状态版本，两者没有自动相等的理由。
在新一轮乱序实验前启用验收选项。页面会先核对查询范围，再拒绝同一范围内低于当前已显示版本的响应。重新运行并保留对照证据。
这个修正只针对约定的范围与版本规则。若服务端版本不可靠，或统计跨越多个独立来源，还需要另建比较契约；它也不会自动修好错误的显示公式。去显示线看看，即使新响应被采用，数字是否一定正确。
交付一条能关联读取编号的时间关系，说明“捕获、到达、显示”各自的证据。至少保留一个未验证条件，不用墙上时钟的毫秒数强行排列不同机器的全部事件。