@no1xsyzy 我的意思是，既然 UI 和 API 不一定有明确的界限，因此选择把某种提供同时提供 UI 和 API 的实现当作哪种接口，最终取决于用户想要做什么。
然而，POSIX 标准化的 vi 中和 ex 不同的部分决定它实际上几乎只能当作 UI。（如果只是要 ex 的功能，那么除去 vi 和 ex 的切换之外，只需要关心 ex 而不是 vi 被 POSIX 标准化。）这种情况下，用户往往不在乎实现的符合性，因为人的操作没有 API 互操作那么多的兼容包袱。
另一方面，基本上用户去用 vi 的理由并不是 POSIX 标准化了 vi，而是因为某种实际上超过了 POSIX vi 功能的可用兼容实现（比如，vim，或者你所说的 elisp 实现的 vi ）恰好存在。（真的只有 vi 的话，这些用户大概会自己另外装个别的编辑器……）
而且就没几个用户期望 UI 部分简陋的接口—— vi 在这里作为操作接口，除了和 ex 相容的部分以及命令的名称本身之外，根本上欠缺标准化的意义。
所以说到 elisp 实现的 vi，虽然你会在乎 POSIX 符合性作为前提，但几乎所有其他用户都不太容易会这样想，反而更容易同意意义在于 elisp+vi，而且重点通常是前者。符合 POSIX 的 vi 这个接口只是个顺便的 bonus （而且原生的命令名称一般还不是 vi ），这种意义下就几乎没什么“ vi 的本质”了。