Because one property doesn't guarantee the other. A modular system may imply that it can be extended. An extensible system is not necessarily modular.
Wayland, the protocol, may be extensible, but the implementations of it are monolithic. E.g. I can't use the xdg-shell implementation from KWin on Mutter, and so on. I'm stuck with whatever my compositor and applications support. This is the opposite of modularity.
So all this protocol extensibility creates in practice is fragmentation. When a compositor proposes a new protocol, it's only implemented by itself. Implementations by other compositors can take years, and implementations by client applications decades. This is why it's taken 18 years to get close to anything we can refer to as "stable".
> E.g. I can't use the xdg-shell implementation from KWin on Mutter, and so on.
Why not? It's open-source software. Depending on your architecture you may be able to reuse parts of it.
But as a more flexible choice, there is wlroots.
> and implementations by client applications decades.
Toolkits implement these stuff, so most of the time "support by client application" is a gtk/qt version bump away.
> This is why it's taken 18 years to get close to anything we can refer to as "stable".
Is it really fare to compare the first 10 years of a couple of hobby developers with the current "wide-spread" state of the platform? If it were like today for 18 years and fail to improve, sure, something must be truly problematic. But there were absolutely different phases and uptake of the project so it moved at widely different speeds.
> Why not? It's open-source software. Depending on your architecture you may be able to reuse parts of it.
"The system is not modular, but you can make it so."
What a ridiculous statement.
> But as a more flexible choice, there is wlroots.
Great! How do I use wlroots as a user?
> Toolkits implement these stuff, so most of the time "support by client application" is a gtk/qt version bump away.
Ah, right. Is this why Xwayland exists, because it's so easy to do? So we can tell users that all their applications will continue to work when they switch to Wayland?
> Is it really fare to compare the first 10 years of a couple of hobby developers with the current "wide-spread" state of the platform?
It's not fare, you're right. I'll wait another decade before I voice my concerns again.
Why would you want to use it as a user? That makes zero sense.
> Is this why Xwayland exists, because it's so easy to do
I don't get your point. The reason it exists is backwards compatibility. There are binaries as well where changing a library is not so easy, and not every version change is equal within a toolkit.
But it's much different to go from X to Wayland then from Wayland to Wayland with one more protocol.
Wayland, the protocol, may be extensible, but the implementations of it are monolithic. E.g. I can't use the xdg-shell implementation from KWin on Mutter, and so on. I'm stuck with whatever my compositor and applications support. This is the opposite of modularity.
So all this protocol extensibility creates in practice is fragmentation. When a compositor proposes a new protocol, it's only implemented by itself. Implementations by other compositors can take years, and implementations by client applications decades. This is why it's taken 18 years to get close to anything we can refer to as "stable".