>Then plan for it, architecturally, so that you can add or enable these features later on, or when you need it. Start with something sensible, appropriate for real-world usage.

This is exactly what Wayland has done though. Few have a reason to run command line tools to change the screen configuration, real world usage is to use a GUI as is common on every other graphical OS.

>You can pass resolution, refresh rate, position and orientation via command line in a simple and understandable way.

A major problem here is because of the way the API works, technically any X11 client can do that at any time. The tool may seem trivial but the way it is implemented has great potential for misuse. It does not even have to be malware for this to cause problems, for example a typo in a random script could seriously screw up your screen. Or another common problem in X11 is with applications setting the resolution to something weird, crashing and then leaving the screen in a weird state.

>This completely confirms second system syndrome. It's only as complicated and non-trivial as you want it to be. I can only imagine what kind of convoluted security nonsense you think of when you say "the right way". Ask the display server for a list of screens and supported resolutions, and then tell it what you want to do with those.

If this was second system syndrome, then it would be in the kernel, not in X or Wayland. Because the kernel is where all the new KMS features happened. Again, the display server is not actually driving this feature. They are relaying information to and from KMS, which is the actual API that configures the screen.