One could presume that for a longer playlist, these two copies of the running order will each span multiple sectors, instead of being contained within the first and second sectors.

Yes. One could also notice that this area isn't really big enough at 512 sectors or 256K. If, in your playlists, you've got four references to each FID (say, once in an Artists playlist tree, once in Decades/Years, once in Genre, and an average of once more in ad-hoc playlists) then playing the whole player with down-down-down uses 24 bytes in this area for each track (8 for the "FID table", known as the "programme" in the player code, and four lots of 4 for the "play sequence", known to us as the "running order").

This means that if you've got more than 10,901 tracks on your player (which is not at all out of the question for a grzelakian, sorry gargantuan, player), and play all of them, then it won't be able to remember your playlist over a power-down. This is a genuine reported problem, and a much bigger spur to completely reorganising the dynamic partition than the 28,000-or-so limit on the per-FID dynamic area. But, as I said, we won't get round to this for 2.0final.

Incidentally, there are three more 512-sector-long playlist dump areas at offsets 512, 1024 and 1536: the three bookmarks.

Peter