> Yes really. It makes no sense that every application has different non unified font rendering or rendering in general. Also things like kinetic scrolling and all kinds of application behavior is now potentially completely different for different applications. It's a mess, we need standardized solutions and such a solution already exists: X11.
A lot of this commentary just doesn't quite reflect reality, even if it's meant well. There's a lot of misunderstanding on what really is different now, or how things are different from other systems.
- Font rasterization and text shaping in all major applications has normed on freetype and harfbuzz.
- Kinetic scrolling/input event handling has (or is in the process of) normed on libinput.
- This is true for X11-based systems as well! The X protocol historically does contain commands for server-side text rendering, but those haven't been used in decades - applications started moving to client-side rasterization ages ago, and the X server moved to using libinput (where its code originated, before then being intentionally moved out).
- In competing systems such as Windows/MacOS, the situation is often the same or reflects the same tech trends. Often there are legacy server-side APIs to do things, but apps have long-sinced moved to newer library APIs. Often there's more than one way to do things (say, text rendering on Windows: Pick GDI or Direct2D) and the perceptual same-ness has just been achieved through effort of alignment. In fact it can actually be worse on other systems nowadays - native app development on Windows has really deteriorated and you can find many apps that just ship freetype/hardbuzz there (bundled with the cross-platform UI lib they picked) and don't match Windows font rendering.
- The separation of duties between the windowing/compositing system and orthogonal library APIs is often the same. For example, in both iOS and Android the display server is not responsible for text rendering in any way. On Android the latter is done through freetype/harzbuzz as well.
- Wayland compositors already share a lot of code in much the same way that X-based desktops did, e.g. by graphics drivers having moved out of the X server into the kernel and Mesa, and input having been moved to libinput.