Why not make Xchars a full graphics interface?

Well, the funny thing is Xchars, other than writing text, is just an xcb interface. It has the entire xcb header file.  It does not need to be graphics, the graphics are in the variables in the attached syntax engine. The syntax engine need only send over the exact wording of the call, and Xchars will blindly execute the call.  That is basically the compositor approach of Wayland, though Wayland does much more.  The client holds the graphics and is responsible for constructing the proper call format.

So the difference here is the universal interface, and the inherent dispatching capability of the console loop.  Console loop only keys on the first word for command search, the rest of he format on args list is application dependent, the standard linux command line approach, except console loop delivers pre-tokenized.

So, no, Xchars is fine as is, strings of text a complete package.  But, yes, we need a QT lite with the universal interface, a loadable.  Given that, we throw away the documentation and instead get packages and syntax engines that do a particular graphics job. They are pre-loaded with graphics APIs that fit the application, mapping those those into token arrays, or let console loop do it. So the high level graphic call look like:  New Report Window, where a report window is enterprise specific, designed in the enterprise data center, and the mapping and the syntax engine widely available.

Get us a QT Lite with universal interface, we will build the semantics with our engine of choice. A one time copy of the API and we have the mappings.  Then with a little knowledge of the dynamics, the enterprise data manager can use tools to construct standard windows, chart, ledgers, and reports for the enterprise.