One of my posts on the Flash display list was quoted recently in a post by Amos Laber on his excellent blog. He said:
So developers like Ben Garney are opting to write their own renderers in order to gain better performance, but that is not an ideal long term solution. A much better one would be to utilize both multi-threading and GPU hardware acceleration for the standard flash Display List.
We are seeing an uneasy alliance between Stage3D and DisplayObject. They work together but not fantastically. How can Adobe reconcile these two different worlds? As Amos points out, it’s a lot like the bad old days in the early 90s when UI libraries were non-existant for OGL/DX and games got by with the bare minimum in terms of UI.
Flash is pivoting from a rich content web runtime to a platform. Things that were previously built into the player need, in my opinion, to become a minimal native API that is enriched by powerful libraries. The display list is a great example of this. 90% of what the display list does can be done as well or better by pure AS3 (in fact, if you look carefully, many of the native DisplayObject methods are actually implemented in AS3). So why not move all that functionality into an AS3 library that comes with the platform, and focus on making the remaining 10% as good and generally useful as possible?
It’s like how an operating system has just a few basic routines for working with the file system, on top of which people build a wide variety of powerful tools like Finder, Explorer, Google Desktop, Alfred, bash, and so on.
The Flash team and the surrounding community has done the software world a tremendous service by developing great ways to build rich interactive experiences. Tweening and the display list are key foundations to those techniques. But they can work anywhere, and in almost any language – take a look at Sparrow, for instance, which provides a lot of the Flash API on iOS.
If I was going to make a prediction for Flash’s future, it would be that long term the display list will take a step back in favor of core APIs like Molehill. Of course, there will still be a display list or display list like APIs, but they will be conveniences on top of fundamental capabilities. This not only follows the trends seen in OS X, Windows, Java, and other platforms, but also enables more innovation and choice on the part of developers.
Ben Garney 
Hey Ben, thanks for the mention.
I am all for more choices, but the core functionality need to solid and robust enough to build on. A good API needs to have decent performance, in addition to an easy to use interface (and not instead of it).
For Flash to remain a viable platform, native AS3 needs to run fast – faster than Javascript or any other dynamic language, but in reality it is painfully slow. Throw anything a bit complex (like Box2D physics) and it starts slowing down. That makes no sense with today’s hardware that features multiple cores and physical threads on any CPU.
I would expect the player to take care of heavy computation and efficient rendering (the 90%) so we developers can build on top of the fundamentals without the need to work around them.
I agree, AS3 execution speed is vital. You can get adequate performance out of AS3 but it is challenging. Adobe is taking steps to improve this but it won’t happen in the short term.
Multithreading is part of the story but not as essential as you might think. Most Flash apps would run fine in a single thread if efficiency was improved, and the Player makes good use of background threading for a lot of its tasks.
Having a big complex set of native APIs is bad for several reasons, IMHO. It introduces security risks. It can bloat player runtime (although the runtime team has done a great job keeping size down). They are inflexible and require Adobe to do frequent updates or developers to work around issues. I think that opportunities to drop native functionality in favor of AS3 implementations are good and should be taken.