The picture data that's recorded between PICTURE ON and PICTURE OFF commands is actually in the same format as the data in a PICT resource. In both cases, they contain a "recording" of some QuickDraw commands. With the right software, you can "disassemble" a PICT resource (or a picture handle, or a PICT file), and see a listing of the "opCodes" that stand for the different QuickDraw commands.
It so happens that one of those commands is "CopyBits." If you do a "CopyBits" command between PICTURE ON and PICTURE OFF commands, then the corresponding opCode (called "PackBitsRect") is recorded, and one of this opCode's arguments is a huge chunk of data containing the pixels that were copied. In this case, 99% of the "recording" is taken up by the bitmap itself, but it's still basically just a recording of QuickDraw commands. There's no reason why you can't, for example, record other QD commands along with the CopyBits; the picture will then contain a "PackBitsRect" opCode (with bitmap), plus the other opCodes you recorded.
In fact, there's no reason why you can't record _multiple_ "CopyBits" commands (each copying a different image) into a picture. When you played the picture back, it would flip through each recorded image, and appear animated. The only drawback would be (just as with animated GIF's), you couldn't control the speed of the "frames."