Interesting perspective. I am the team lead on Mir and recognise some of the history you report on. But I don't interpret them all as you do:
Mir (display server): Canonical's alternative to Wayland. Pivoted to IoT. Wayland won.
This conflates the Mir display server and the mirclient API. mirclient was used before Mir switched to Wayland. Support for Wayland was introduced in 2017 and mirclient was dropped in 2021. Wayland did win, but Mir didn't lose.
C-02 | UBports Perpetuating the Pattern
UBports did not create the architectural problems. They inherited them.
But after 8 years, they have not resolved any of the fundamental ones:
Halium: still on vendor EOL kernels
Mir: still not standard Wayland-native
Mir is Wayland-native (for at least 5 years) and the basis of several popular desktop Wayland compositors:
Lomiri
Miracle-WM
Miriway
Mir 2.x IS a Wayland compositor. Standard Wayland client apps DO run via XWayland.
That misunderstands Xwayland - that allows X11 applications to run on a Wayland compositor,
The mirclient protocol — the native app protocol for UT Click apps — is not standard
Wayland. It is a Mir-specific extension. Miroil preserves it as a compatibility shim
over Mir2. The Mir team lead proposed Miroil in 2021 as a low-priority project.
In 2026 it is still not complete.
Miroil is complete and has been in maintenance mode since 2021, It provides API compatibility for Lomiri to make migration from Mir 1.x to Mir 2.x easier. It is not related to mirclient in any way.
Phosh's phoc uses wlroots. wlroots speaks native Wayland. GTK/Qt apps run natively.
No containers. No compatibility shims. No mirclient. One protocol. Standard.
To paraphrase: UBports Lomiri, Canonical's Ubuntu Frame, Matt's Miracle-WM, my Miriway and Budgie's Mirpie use Mir. Mir speaks native Wayland. GTK/Qt apps run natively. No compatibility shims. No mirclient. One protocol. Standard.
Using containers is a OS choice, not a compositor choice.