The three main hurdles to porting existing Flash projects to iOS with AIR

Question

The purpose of this discussion is to identify significant problems currently preventing AIR for iOS from being a viable solution for porting existing Flash apps.  These issues have been largely ignored by Adobe, so I hope that everyone will add to this discussion if you have also run into these roadblocks in targeting iOS with the AIR SDK.  I hope that Adobe staff will address and provide some much needed information with regard to fixing these problems.
There are 3 main problems with targeting iOS currently, which are probably affecting anyone who is trying to port a project that is both medium to large in size and makes use of SWF loading.  Pretty much any project that has a MVC architecture is going to load SWF assets that are compiled against a view class, so this is likely affecting many people.
1. Bug - ADT packager runs out of memory when packaging "large" numbers of SWF assets
https://bugbase.adobe.com/index.cfm?event=bug&id=3511656
This is a blocking bug that prevents packaging projects with a large number of SWF assets.  It is preventing me from being able to package all the needed assets for my project.  I provided Adobe with my project to package a couple months ago so this bug can be reproduced in house and fixed.  The Adobe employee who was handling this never tried to reproduce the issue and has stopped responding to email and comments in the bug.  Adobe, please have someone take charge of testing and fixing this bug.  It seems like it would be a straightforward fix once the failure is reproduced within a debugger.
Has anyone who has encountered this problem determined the number of files or classes where it starts to fail.  I've spent some time trying to reverse engineer what the packager is doing when it runs out of memory, so think I can determine how many classes it's working with, but obviously the size of the classes will be variable and so this number will probably be more of a range where we start to get into the failure state.
Please let me know if you can reproduce this issue with your project with many SWF assets and upvote the bug if you are already aware of this one.
2. Bug - SWF reloading when doing a "real" (AOT) compile
https://bugbase.adobe.com/index.cfm?event=bug&id=3636385 
There is already a forum post that covers the history of this issue (http://forums.adobe.com/message/4920638) but that also covers some issues in older AIR builds with loading of any SWF asset (previously fixed), where this bug deals specifically with reloading of SWF assets that include compiled bytecode (ABC).
The expectation here is that all versions of the Flash runtime should handle SWF reloading with ABC in the same way, so that a single codebase can be used to target web and iOS (or any other platform).  This is the only issue of the 3 that has a legitimate work around, in my opinion, because the assets can be cached within the app within a loading manager layer.  All the application code that makes loading calls can stay the same, and a compiler flag can be used to enable this caching for iOS builds, with subsequent requests returning a new instance of the cached asset.  This can potentially lead to a very bloated memory footprint for the running app after a period of time, though, which could make some apps perform poorly, so a bugfix is ultimately needed.
3. Unimplemented feature (?) - The constraint that a single ApplicationDomain is used when running AIR for iOS 
I did ask about this in the same forum post as SWF reloading but didn't get an Adobe response.  Why does this constraint exist?  My guess is that the AIR runtime for iOS simply hasn't implemented multiple ApplicationDomain support at this point, and that this was done to focus resources on other high priority features for the iOS runtime.  It's possible that there is some aspect of the iOS operating system that makes it difficult or impossible to implement this feature, which may be why it's been avoided to this point, but obviously this is all conjecture without hearing from Adobe on it.
This is a major issue that needs to be addressed.  For us, the problem is that our SWFs for multiple instances of the same type of asset use the same name for the AS export.  For example, each item an avatar can equip is a single SWF with multiple sub assets -- the parts which comprise the item.  Each of the parts will have an AS export name based on the avatar facing and where it is equipped, like "fv_head".  This naming is consistent across all items, so we will load a lot of assets containing "fv_head" simultaneously.  This normally works fine because the default behavior for Flash has always been that each SWF is loaded into a new ApplicationDomain instance, but for iOS a single ApplicationDomain must be used, causing these names to collide.  The last SWF loaded containing a given AS export name overwrites the previous ones of that name.
The work around for this, and I use that term loosely, is to go through and uniquely name every AS export in every asset where sets of assets with the same export name is used. For us that is hundreds of items with multiple exports.  Maintaining unique naming across all these parts is also a very error prone process, not to mention all the code that manipulates the parts needs to be modified to handle the new naming and make sure it's referring to the now uniquely named assets.
The expectation here is that all versions of the Flash runtime should handle asset loading in the same way and place each loaded asset into its own ApplicationDomain container as the default behavior.  I'd like an Adobe employee to address my assumption that this is an unimplemented feature of AIR for iOS at this point, and let the community know if a solution for this will be implemented.
Summary
All three of these issues in combination are a major roadblock to porting existing Flash games to iOS with AIR.  Issues with one can make it hard to test and try to work around others.  All need to be fixed, but If I could only pick one of these to fix, it would have to be issue 3 -- that lack of proper ApplicationDomain support when loading assets.  This issue is completely inconsistent with standard Flash behavior and creates a major roadblock to ports of existing applications with no viable solution for a workaround.
I look forward to Adobe's feedback on each of these issues and hopefully fixes that will allow those of us working with AIR for iOS to get our products to market.

Answer 1

About the 3rd issue being an AoT design limitation, I'm not sure I understand why it's necessary to know during AoT packaging what the domain is that a child will be loaded into to be able to have SWF loading work as on the browser.
Isn't the ApplicationDomain an internal construct in the AIR runtime that you guys define in order to manage namespaces of loaded SWFs?  To be clear, when I say "runtime" I know that the resulting code isn't being interpreted within the iOS app, but clearly you have a set of AIR libraries that get compiled into the IPA that provides support for all the Flash APIs.  If that's the case, then wouldn't it be possible for the iOS version of the AIR libraries to define a new ApplicationDomain on the fly when code that has been cross-compiled to iOS native code loads a packaged SWF?
I don't have a clear picture of how ApplicationDomains are managed internal to the runtime of course, but a little more detail would be very helpful.  Thanks.