最后把整句话翻译成人话
这句话其实是在说：tmux 为什么比 Screen “舒服”，核心不是功能更多，而是它从底层架构上重新设计了一遍。
可以把这句话拆成 4 个概念。
1. Screen 背负了“历史包袱”
Screen 是 1987 年左右的产物。
那个年代的软件设计思路和今天很不一样。Screen 一点点增加功能，最后容易变成：
原来的代码 + 后来加的功能 + 为兼容旧行为留下的特殊处理 + 更多特殊情况
就像一间住了 40 年的老房子：
最初的房间
↓
后来加一个隔断
↓
再加一根电线
↓
再打一根洞
↓
再接一根管子
↓
最后谁也不敢动墙
所以这里的：
“80 年代那团杂乱如麻的状态机”
不是说 Screen 一定“代码很烂”，而是在强调历史演化造成的复杂性。
2. tmux 可以重新思考：“终端复用器到底应该是什么？”
Nicholas Marriott 写 tmux 的时候，没有那么重的历史包袱。
所以他可以重新定义整个模型：
物理终端
↓
tmux client
↓
tmux server
↓
session
↓
window
↓
pane
↓
你的 shell / vim / top / agent
这个结构非常重要。
Client 和 Server 分离意味着：
你眼前这个终端窗口，只是“观察和操作 tmux 的客户端”。
真正维持工作状态的是：
tmux server
所以：
SSH断开
↓
client 消失
↓
server 还活着
↓
session 还活着
↓
vim / shell / Agent 继续工作
重新 SSH：
SSH连接
↓
重新启动 tmux client
↓
attach
↓
重新看到原来的世界
这就是你前面一直在讨论的那个思想：
连接不是工作本身。
3. 什么叫“libevent 事件驱动”？
可以先不要把 libevent 想得太复杂。
传统程序很容易写成：
等输入
↓
处理输入
↓
等另一个东西
↓
处理另一个东西
↓
再等
而事件驱动更像一个调度中心：
┌─ 键盘来了
│
事件循环 ───────┼─ SSH数据来了
│
├─ 子进程有输出
│
└─ 窗口大小变了
谁发生了事情，就处理谁。
所以 tmux 可以同时管理：
客户端输入
SSH连接
多个session
多个window
多个pane
shell输出
终端尺寸变化
各种socket
而不需要为每一个东西搞一套互相纠缠的等待逻辑。
libevent 本质上就是帮它管理这些“事件”。
你可以暂时把它理解成：
一个高效的“事件总管”。
4. 什么叫“正交的命令控制协议”？
这个词最值得理解。
正交 = 不同功能彼此独立，可以自由组合。
例如 tmux 有很多命令：
tmux new-session
tmux new-window
tmux split-window
tmux select-pane
tmux attach
tmux kill-session
这些命令分别负责不同事情。
于是你可以组合：
创建 session
+
创建 window
+
创建 pane
+
选择 pane
+
发送命令
而不是：
“如果你处于 A 状态，然后发生 B 事件，再根据 C 状态调用 D 功能，否则走 E 分支……”
这就是所谓状态机复杂度被拆开了。
最后把整句话翻译成人话
原文：
因为不需要像 Screen 那样背负历史包袱，Nicholas Marriott 才能跳出 Screen 80 年代那团杂乱如麻的状态机，采用现代的 libevent 事件驱动、清晰的 Client/Server 架构，以及正交的命令控制协议。
其实就是：
Screen 是在几十年历史上不断修修补补出来的；tmux 则有机会重新想一遍“终端复用器应该怎么设计”。所以 tmux 从底层就把事情拆清楚了：事件交给事件循环，连接交给 Client，工作状态交给 Server，session/window/pane 各自独立，命令也可以自由组合。
这也是为什么你感觉 tmux 不只是“功能比 Screen 多”，而是“用起来更顺”。
真正的差异在于：
Screen
历史 → 功能 → 补丁 → 兼容 → 越来越复杂
tmux
重新建模 → 分层 → 解耦 → 组合 → 更容易理解
所以你那篇“工具的尊严”里，其实可以再往前走一步：
好的工具不是把更多功能塞进旧架构，而是敢于重新定义问题。
这句话比单纯说“tmux 比 Screen 好用”要深得多。