回答:
なぜウェイランド/ウェストンではないのですか？
まず明確な説明：Waylandは、クライアントアプリケーションがコンポジターコンポーネントと通信する方法を定義するプロトコル定義です。サーフェスの作成/破棄、グラフィックスバッファの割り当て/管理、入力イベント処理、シェルコンポーネントの統合のための大まかなプロトタイプなどの領域に触れます。ただし、プロトコルの定義を評価した結果、Waylandプロトコルは要件を満たしていないことがわかりました。まず、3D入力デバイス（Leap Motionなど）のような将来の開発を考慮した、より拡張可能な入力イベント処理を目指しています。ただし、Waylandの入力イベント処理は、Xの入力イベント処理セマンティクスによって導入されたセキュリティ問題の影響を受けません（これを指摘してくれたDaniel StoneとKristianHøgsbergに感謝します）。モバイルのユースケースに関しては、入力メソッドの処理は、ディスプレイサーバープロトコルにも反映されるべきだと考えています。別の例として、プロトコルのシェル統合部分を特権があると見なし、クライアント側のプロトコルで定義されたシェル動作を避けたいです。
ただし、クライアントとディスプレイサーバーコンポーネント間の通信を標準化しようとするWaylandの試みは非常に賢明で有用であると考えていますが、要件が異なるため、プロトコル統合のために次のアーキテクチャを採用することにしました。
非常に明確に定義され、十分にテストされ、移植可能なプロトコルに依存しない内部コア。ディスプレイサーバーを任意のグラフィックススタックに移植し、複数のプロトコルにバインドできるようにするフロントエンドファイアウォールを備えたアウターシェル。
要約すると、次世代のユーザーエクスペリエンスを提供するための基盤としてWayland / Westonを選択したのは、要件を完全に満たしていないためです。さらに、プロトコルおよびプラットフォームに依存しないアプローチにより、プラットフォームおよびデバイスのフォームファクター全体で一貫した美しいユーザーエクスペリエンスという目標を確実に達成できます。ただし、ディスプレイサーバーにWayland固有のフロントエンド実装を提供するか、最終的にMirと通信するlibwaylandのクライアント側実装を提供することにより、Waylandサポートを追加できます。
ここでより詳細な議論があります：https : //wiki.ubuntu.com/Mir/Spec?action=show&redirect=MirSpec
そして、Mirテクニカルアーキテクトから：
http://samohtv.wordpress.com/2013/03/04/mir-an-outpost-envisioned-as-a-new-home/
詳しくは：
QとAのJono Baconはこれに数回答えました。彼の最新の回答はこちらです：
http://www.youtube.com/watch?v=6Oa2psAewtg&feature=share&t=56m36s
JonoのQ＆AやLinux Unpluggedに対するPopeyのコメントから集めたものから、ポイントは次のように要約できます。