Jon
Keep in mind that this is my personal order and is based on what normally is worked on within a decompiled default bgl making it easier to scroll and find certain data more quickly.
I have another list besides this one if I am writting a XML from scratch. It does not change this list order but adds additional element tags nested properly so FS loads data at runtime correctly.
The following is Facility Data (only) List for a FSX default bgl that must nest inside the Airport Record
<Airport Header
<Services
<DeleteAirport ("TRUE" "FALSE" list)
<Tower
<Runway
i.e. all runway data as shown in SDE down to and including
<Ils end
<GlideSlope
<DME
<Start type
"RUNWAY"
"WATER"
"HELIPAD"
<Helipad <-- denotes the default visual ground markings and not a Object. LAT/LON should agree with the Starttype so they overlay
<RunwayAlias (optional if listed)
<RunwayStart (optional if listed)
<Com
<TaxiwayPoint
<TaxiwayParking
<TaxiName <--- SDK says should be listed last out of these 4 Taxi's but works here
<TaxiwayPath
<Aprons
<ApronEdgeLights
<BlastFence
<BoundaryFence
<Jetway
<TaxiwaySign
<Approach
<Waypoint
<Ndb (TERMINAL_NDB) only
Note
The approach data record is normally the largest record. It does not have to be close to the runway info. Only the first line in the approach record references the type approach for the runway. All legtypes and Transistions are from the approach plates and not from the Runway Record listed at the top.
The Airport Record can only contain Tower, Services, Com, Runway, RunwayAlias, Aprons, ApronEdgeLights, TaxiwaySign, Waypoint, Approach, Ndb, Helipad, Start, Jetway, BlastFence, BoundaryFence, DeleteAirport data.
The SDK is not very clear in this area in the way it is written when you get down toward the bottom part of the document. It leads you into thinking that VOR's, Markers, Geopols, Routes, etc. are nested inside the Airport record and they are not.
I don't see a problem in the way you list all the Library objects last. It would be hard to nest them inside the associated ICAO code.
I am emailing you a bgl with the master xml for my next post. This will allow SDE to see how a single bgl is used to incorporate an entire XML build from start to finish.
Decompiling multiple airports in a single default bgl is one thing but when decompiling a single airport bgl that is hand written must also be a consideration which you have already come across with AFCAD issues.
EDIT
After reading this I need to explain some additional information.
The ILS record that nest with the Runway is owned by the Runway and only serves one purpose. The purpose is so the User Planes radio can receive the ILS freq. and lock onto the Localizer (GS/DME if listed). Many think that by adding a ILS to a runway (using AFCAD) also causes ATC to recognize the ILS and this is not so. ATC sees the runway as a Visual runway and closes it if weather falls below minimums.
The only way to get ATC to understand a ILS exsits is to write a XML companion ILS Approach in the Approach data record using <Approach type="ILS" for that runway number. The ILS which is owned by the Runway only extends into the surrounding scenery by about 28NM and this is hard coded. When the Approach data owns the ILS companion record then ATC uses the invisible scenery of a airport which in most cases is a 108NM radius from the ARP.
This is one of the reasons the runway ILS is broken by AFCAD if a user/scenery designer renumbers a runway that has associated instrument Approach data. ATC no longer understands the ILS when it is no longer tied to the runway number that has been changed. Of course on the surface the User Plane stills sees the ILS on the CDI and thinks everything is ok.