我不认为 Linux 桌面过于分散是件好事，分支应该重新加入主要项目，从而让 Linux 体验更好。
因此，如果在未来某个时候社区/Canonical 必须在 Unity 和 Gnome-Shell 之间做出选择，那么合并这两个项目会有多难？
答案1
考虑到 Unity 和 Gnome Shell（又名 Gnome3）几乎共享整个操作系统堆栈。截然不同的部分是 shell 部分，即视觉元素。我担心，在 shell 方面，它们不可能合并。
- Gnome Shell 基于 JavaScript，开发人员严格拒绝任何非 javascript 的代码。
- Unity 基于 Python、C 和 Vala，它曾经使用与 Gnome Shell 相同的合成器，但由于速度太慢而转移到 Compiz。
更有可能的是，项目之间会相互交流想法。每个项目都会有正确的地方，也会有错误的地方。随着时间的推移，具有更好设计意识、谦逊地接受用户需求的项目以及最终具有更好经济效益（更多开发人员）的团队将发展得更快更好。
答案2
它们在技术和功能层面上确实存在很多差异。它们还专注于不同的（尽管相似）创意方向，而且它们都处于开发阶段，尚未最终确定。它们可能需要数年时间才能找到一种证明自己行之有效的产品。
任何时候，想法都可能横跨虚空。这种情况显然已经发生过好几次了，这没什么不对，虽然它在界面意识形态层面上有所帮助，但它对帮助开发人员团结在一个共同的编程语言或排版程序上毫无帮助。
我认为最终可能是一个解决方案“获胜”（通过在有用功能上取得进展）并被另一个阵营采用，但话又说回来，很少有类型的开发人员比 FOSS 开发人员更坚忍不拔。这甚至可能需要像 Wayland（本质上是 X 的替代品，具有自己的合成层）这样的方案来混合各种方案。
我不会打赌其中任何一个会远远超过另一个。至少，在底层技术发生变化之前不会。
答案3
似乎不太可能。Unity 的大部分内容都基于 compiz，而 GS 则构建了一个新的工具包（基于 Mx）和堆栈，以及一个新的 WM。GS 可以更容易地模拟 Unity，而不是反过来，我不会惊讶于看到这样做的皮肤，但它们可能不会集成。从根本上讲，这是一个窗口管理器的问题。Gnome 构建了自己的 WM（实际上是 Metacity 到 Clutter 的移植，并进行了许多改进），GS 是 Mutter 的一个插件。JS 用于几乎所有的界面元素，而 C 用于库中（Mutter 用 C 编写）。JS 是体验不可或缺的一部分（考虑到在 JS 研究上投入了多少精力，所以事情应该会迅速改善，但并不是必须这样做，这并不是一个坏主意）。Unity 采用了现有的 WM 并对其进行了扩展，并围绕它构建了一个界面（非常类似于 GS），但使用了现有的工具包，因此除非您使用 Qt（我认为他们最终会完全转向它），否则在 Unity 中创建 gl 上下文会更加困难。 Unity 对 Canonical 来说是个不错的选择，因为他们想创建一个独特的环境，因为它可以重复使用很多东西，但如果不密切关注上游，他们就有可能在 gnome 方面始终落后于技术曲线（这也是他们可能转向 Qt 的另一个原因）。所以，如果你能说服 Gnome 或 Canonical 放弃他们的一个窗口管理器，你也许可以进行合并，但这有什么意义呢？让他们创建两个不同的桌面，看看哪个更好。