Gary,
Please be careful with what you refer to when writing "XML". XML as a format can save anything, hence your questions reads a bit like "Should it be a bucket, or something that can hold water?".
I see Jon read your question as "should it be the FSX XML format, or something else", which is how I would choose to interpret it as well, but it does become a bit unclear when using the general term "XML" to cover a specific XML format.
John,
Do not use comments for anything but comments. No tool can operate efficiently on comments (think XSLT etc).
As far as I have seen Jon, your work is a good object wrapper of the FSX structure. I do not see it used as the SDSX project structure for a number of reasons:
1) It would make your library less generic - other tools will also need to read and generate FS scenery, without being hooked up to an SDSX specific structure.
2) It would tie the scenery file structure to the logical structure. For large parts of it, SDSX needs to handle what goes in which scenery files, I certainly can't be bothered as a user... and I can even less be bothered sitting moving things around manually because preferences change later on.
3) The saving of a project (as opposed to generating a scenery) is up to a data mapper. A datamapper saving to a XML format is an obvious choice, but we might also provide an SQL datamapper later on, specifically on the server side.
4) As you mention, no logical place to handle the extra structure we need (folders used to organize large sceneries, readme information, position information for KML generation, internal work model or ready for release etc). Some of your classes are provably so generic we can use streight mappers in the SDSX domain model, but still we should use a wrapper class allowing later diviation.