Jon, glad to see (in your new "fixed" thread) that the problems I reported earlier in this thread have been fixed. But, alas, a developer's work is never done. 
Yesterday, I discovered a number of hold-short nodes from my FS9 AFCAD were reversed in FSX after being processed by SDE. It appears that this is a consequence of SDE changing the order of the taxiway path records. The final orientation of a H/S node seems to depend not only on its "orientation" field but also the sequence in which the taxiway segments it joins are drawn. It seems that the first segment drawn establishes the "in" direction for the H/S node. If the order of segments is reversed, the node is drawn in reverse, even though its "orientation" field is unchanged. In fact, this turns out to be the cause of my "visible H/S node" problem reported a couple of days ago.
I also noted, but I'm not certain of any adverse consequences, that the order in which the taxiway points are declared is a bit unorthodox - obviously a result of alphanumeric label ordering. The current order is TaxiwayPoint 0, 1, 10, 100, 101 . . . 109, 11, 110, 111 and so on. I mention it only because the problem above may be related to it.
While I was able to manually correct the reversed H/S problem, the result was substantial differences between my FS9 AFCAD taxiway specification and the FSX version of the same taxiway network. Ideally, to minimize the effort of continued support of both FS9 and FSX versions of CYYJ (2007), the taxiway network specification should be identical.
Fortunately, there's a workaround - based on the one I used to avoid the apron edge lighting problem, i.e, use both AFCADs in FSX, with the FSX AFCAD specifying only those elements that are different in FSX, e.g. runways. (FSX provides a number of useful new options for runways.) The deleteAirport functions in the FSX AFCAD, which must be the last loaded (careful naming is required), control which AFCAD is used for each category of data.
Sorry to have to report this. I presume otherwise, you'd have spent the day at the beach.
Don
Yesterday, I discovered a number of hold-short nodes from my FS9 AFCAD were reversed in FSX after being processed by SDE. It appears that this is a consequence of SDE changing the order of the taxiway path records. The final orientation of a H/S node seems to depend not only on its "orientation" field but also the sequence in which the taxiway segments it joins are drawn. It seems that the first segment drawn establishes the "in" direction for the H/S node. If the order of segments is reversed, the node is drawn in reverse, even though its "orientation" field is unchanged. In fact, this turns out to be the cause of my "visible H/S node" problem reported a couple of days ago.
I also noted, but I'm not certain of any adverse consequences, that the order in which the taxiway points are declared is a bit unorthodox - obviously a result of alphanumeric label ordering. The current order is TaxiwayPoint 0, 1, 10, 100, 101 . . . 109, 11, 110, 111 and so on. I mention it only because the problem above may be related to it.
While I was able to manually correct the reversed H/S problem, the result was substantial differences between my FS9 AFCAD taxiway specification and the FSX version of the same taxiway network. Ideally, to minimize the effort of continued support of both FS9 and FSX versions of CYYJ (2007), the taxiway network specification should be identical.
Fortunately, there's a workaround - based on the one I used to avoid the apron edge lighting problem, i.e, use both AFCADs in FSX, with the FSX AFCAD specifying only those elements that are different in FSX, e.g. runways. (FSX provides a number of useful new options for runways.) The deleteAirport functions in the FSX AFCAD, which must be the last loaded (careful naming is required), control which AFCAD is used for each category of data.
Sorry to have to report this. I presume otherwise, you'd have spent the day at the beach.
Don
