My suspicion is that XML and friends get chosen for compelling social reasons. It's not a language that anyone would want to do the actual software implementat

My suspicion is that XML and friends get chosen for compelling social reasons. It's not a language that anyone would want to do the actual software implementation in. That's important because, if you pick an existing language, then everyone who plans to use some other language is going to see that choice and assume it means that their language is either unsupported or will be a second-class citizen on that UI toolkit. They might not be wrong. Creating a whole new language that's custom-tailored for UI layout avoids that problem, but will also be off-putting, since people will perceive that they have to learn a whole new language just to use your UI toolkit. And just slapping it into a mess of library calls that people can call from any language is perhaps the worst choice of all. GUI toolkits, for whatever reason, always end up being object-oriented. Meaning that you've got to export an object-oriented API. Meaning you've got to either implement it in an object-oriented language that probably has a deeply incompatible and possibly not even standardized ABI such as C++, or you've got to go to great lengths to Greenspun an object-oriented system into a procedural language that can export a C-style ABI. Neither of those is fun. In summary. . . yeah, XML is an awful choice. It's easily the worst option, aside from all the other options, which are even worse.