neovim 确实在前后端分离做headless 方面做了很大的工作，未来的几个版本内可能就能实现类似 vscode 那样的远程架构。
不过现有的所有 neovim 的 GUI 本质上和 CLI 没啥区别，neovim 也没有提供多少 GUI 的 feature（可甚至可以直接说就是压根没有）。
而 emacs 很早以前就有 GUI 客户端了，目前也有大量的 GUI only 的 feature，比如一个 buffer 内不同大小的字体，buffer 内嵌入图片视频等等等，以及用得最多最常用的 childframe。如果做一个纯后端的 emacs，我很好奇对这些本身就是基于 GUI 的功能的兼容性是否还能保证？
由于网页的实现本身是基于单一窗口的，我觉得单一 web 投射到多个 window 的意义不大。所有具有 webkit/webview 的技术我觉得都可以用来做这个前端。
其实不用担心，新前端的目的是一劳永逸解决多线程，渲染性能和GC三个顽疾。
不管qt还是web的渲染能力肯定都比emacs内置的图形基础设施强很多。
当同样功能的GUI需求被新的前端满足后，用户会自动迁移到新的插件的。
elisp插件最宝贵的资产是对文本的处理和elisp语言热替换的部分，而不是GUI的部分，这个论点已经被EAF证明了。
Rust/Qt怎么感觉不如直接用cpp，绑定弄好了也不一定好用，浪费时间也提升不了什么开发效率。
歪个楼，最近看了下 helix editor，感觉挺不错，插件系统他们考虑使用一个rust的 scheme实现，gui也在考虑中
弱弱的提个建议：感觉可以把多线程+GC优化 与 UI提升 进行解耦。相信对于terminal的用户前一个需求也是十分期待的。
就从我个人的使用体验而言，UI的提升远没有性能提升来的迫切，尽管我只使用GUI 
实锤C++人厌狗嫌，宁愿绕远路搞rust binding也不愿意直接用C++ 
支持 zbsd
感觉如果不是像neovim那样独立于vim发展，又没有Emacs维护者们协同，还挺难搞的。
如果是我，我会直接对Emacs动手。
最大的问题就是GUI和TUI如何并行发展
我觉得这个根本不是问题，上面的懒猫大佬已经说了根本不在乎 TUI，
太割裂了也不好呀
TUI缺少很多图形库必备的基础设施， 如果要将就 TUI, GUI基本上就没有出彩的地方。
TUI 对于需要登录远程写代码的人来说是刚需了。好在这类人不算多，目前的 Emacs 将就够用，对于 TUI 的期待也没那么高。
从“经济学”角度考虑，放弃 TUI 用户是合理的。
远程写代码，为何不是 New Emacs下一个插件，类似于 Vscode 连接 WSL 这种操作。 
那是不是可以理解, 当前的TUI版本,其实速度已经很可以了.
不要问「为何不 x」，应该问「为何要 y」。
我认为涉及到UI部分的不考虑TUI是合理的，毕竟缺少必要的库支撑（也不是全部）。但是，底层部分也许可以复用，比如lsp，利用多线程、异步等优势提升性能，就想lsp-bridge做的那样。这些部分无论是TUI还是GUI都是可以受益的。不知道这样理解是否正确，请懒猫指正！
直接用C++ qt会不会更方便，qt的其他binding问题都很多，实在不行qml也可以考虑
其实我也觉得可行 