All that about "timelines" and "movies" threw me and the GUI interface to manipulating this machine just made it all more obtuse. But I'm starting to get it. Every description I've read in books was built on piles of unvoiced assumptions.
A "movie" can be an image, a line drawing (either/or procedurally created in ActionScript or manually created using the GUI environment), mpeg data, or perhaps other things. If the movie is a line drawing, it may be "tweened" so that it has a start shape and end shape and morphs between the two in in-between frames. This may be as simple as a zoom effect where the object gets larger or smaller over time. Any type of movie may have any of the basic simple attributes change over time, as the animation progresses: x position, y position, alpha transparency, rotation, and other things. The shift in values for the variables can be arranged in the GUI builder.
Each movie may have code attached to it. onFrameEnter runs each frame the movie appears in and is the place where tweaks to parameters are usually made: tweaking x position, or stopping the movie, and so on. Buttons are a variation on movies that have onRelease and other events.
The timeline in the GUI marks up when the movies start and stop. Any number of movies can be stuck in there and their layer properties decide which appear over which other ones. A lot of movies are full-screen, covering up everything below them. Layers can change while the movie plays and this varies from the order that the movie clips are listed on the screen.
A few things can happen when a movie ends: it stops (corresponding to the stop() function) and stays on screen, not moving. Or it's layer or alpha (usually alpha) is tweaked to make it disappear behind (or disappear over) other things. Or its x or y is tweaked to move it off-screen. Or it might be configured to play again.
"Movie" is also the name given to the assemblage of movie clips/objects, the timeline, and any ActionScript code in the system.
It is entirely possible to make a "movie" (.fla file) entirely in code linked to resources such as jpegs, for example using mtasc and swfmill. The work of starting and stopping movies clips, moving them on and off of the screen, and tweaking variables over time can be done entirely in code.
Let me get back to you with the details...
Other thing of note... rendering itself is entirely non-procedural. There's no draw() method, and no clipping. It's implicit. It'll re-render every stupid thing on the screen 30 times a second (or whatever framerate gets picked) even if nothing is moving, calling onFrameEnter for each object that isn't stopped as well (I think that's right).
Since everything gets re-drawn every frame without any sort of request being made for it to happen, affecting on screen objects by tweaking variables works. ActionScript programmers completely embrace this philosophy. Movies, buttons, network layer stuff, and about everything communicates in a typical ActionScript app not so much by calling methods on things but by setting global variables or instance variables in little objects. Next frame, 1/30th or 1/10th of a second later, code somewhere else will notice the variable has changed and do something else. The general effect is sort of a big, broken up program that runs top-to-bottom n times a second while at the same time graphics are redrawn.