We are not working on this right now, because there are still other features in GSX we would like to add first.
In any case, it's not that there aren't alternatives to operate jetways.
More enlightened developers, like UK2000, already used the proper FSX method to do moving jetways, which means they will work nicely with GSX without anything else added, and other good developers (like Flightbeam) are following for their upcoming sceneries, without even mentioning the fact we always had custom and proper moving FSX jetways in all our sceneries, since we released Zurich in 2007. And of course, all FSX default airports have moving jetways.
It's fairly obvious that, with GSX out, more and more developers will likely do the right thing and use whatever feature FSX offers by default, it's for their own sake, because a scenery with static jetways will always be perceived as not complete, more so with GSX out, pointing out the issue.
Supporting default FSX jetways doesn't prevent a developer to provide AES support too, because the preparation work involved to do a scenery that uses FSX default jetways it's the same that is needed to support AES (having buildings and jetways separated, basically).
About what we might do with jetways, it's not certain right now. We would rather not pursue the "pay-for-airport" approach, which is required to do individual jetways for 3rd party airports that have static ones: it wouldn't make much sense and it wouldn't be fair to charge people JUST for jetways, to supplant what the original developer should have done in the first place. So, it's very likely that, should we ever replace the FSX jetway animation system entirely, we'll likely do it only for our own airports and maybe (a big "maybe) default ones, but not 3rd parties.
