Let me add some comments on this to kick off. In eMinerals we have made a lot of progress using CML (chemical markup language) to represent our materials/chemical/modelling data. CML has the opposite problem; being extensible it has extended, and we have evolved a way of using CML. The point is that our use of CML leads to a very rich way of representing data, such that in one file we not only markup a huge set of data values generated by the simulation code, but we also represent metadata about the code and the specific job, and the complete set of parameters that defined the job. When we turned to KML this is what I missed. We are thinking about GML and GeoSciML as possibilities to supplement data.
Our view on XML is that we want to capture the complete story associated with data. XML is good for this, as opposed to an image say, and it is good that Geobrowsers can take in XML (KML) files as opposed to only images. However, as you point out, KML is really missing a lot of the additional capability you want.