I'd be a little concerned that this is just one person doing the work, but we'll see if others join in.
I think trying to improve the quality of such old code bases is good and "don't touch it in case something breaks" has caused more problems than it solved, but in this case the lack of testing caused X to die when someone runs xrandr. Not exactly a vague use case. Large restructuring work and taking care of tech debt is good, but it should go along with diligent testing.
Until all the work is done, I don't think this will be a very stable alternative to X.org. I also don't think many people will follow this guy to the new project because the comments on the MR seems very "this guy versus everyone else".
Even if the fork stabilizes, that's just where the journey begins. The X.org system interacts with tons of other systems (the kernel and GPU drivers, among others), so that work need to be kept up with. At the same time, developing all of the new features the dev wants to add will be pretty useless unless applications start making use of them, and they're not going to if the project remains small.
If the anti-Wayland people unite behind this project and maintain their own X fork, there may be promise in this fork. But looking at the history, this is more likely to become another X12/Y11, or maybe a Mir if he can get a distro to back him.
I think this comment from an Xorg maintainer sums things up (from this issue: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1797 ):
> Changing calls pScreen->DestroyPixmap to dixDestroyPixmap doesn't meaningfully improve the code or make it easier to reason about. Moving byte-swapping of requests and events from one function to another doesn't make the code more robust. Cosmetic changes to the way length fields are written doesn't help with byte vs. word unit confusion, or keep you from writing the wrong amount of data. You're just moving the complexity from point A to point G, not reducing it.
> It is possible to reduce the complexity of the code, by delving deep into the interactions between DIX/MI/FB/DDX to flatten the code flow, making some deep structural changes. Or by using structured (de)marshalling through XCB. Doing this would be incredibly risky, but at least have a much higher payoff than just cosmetic shuffling because it is 'cleaner'.
> The immense value X11 has - that it always had and will have for decades to come - is its backwards compatibility, still being able to run 40-year old apps. You correctly called the codebase 'fragile' - you've been finding this out as your changes repeatedly break things. If you're breaking apps, then what exactly is the value in a codebase which is 'cleaner' to your subjective standard but doesn't actually work?
If nobody fixes this then the fork is dead in the water anyways.