This little project is still progressing very well. I am now dynamicly loading a list of worlds into WRAM on startup, and dynamically loading maps into WRAM every time the game changes levels. Besides the maps, I can also load a new palette every level, new starting times, a new warpzone table, and a couple of other minor elements.

Each ROM page used for game element storage starts with a lookup table of up to 255 pointers, each of which points to a structure in that page of ROM that contains the game data. The game data itself consists of data to feed to the SMB game engine, as well as references to other lookup table entries (possibly on different pages).
The "hijacker" code navigates these data structures, loading necessary data into RAM. It uses some fixed structures (for things such as palettes and other indexed tables), but for the bulk of variable length data, it uses a lightweight heap. When it comes time to load new data, it simply rolls back this heap to the prior location. (No worries about fragmentation!)
The entire system is designed to be forward and backward version compatible, i.e., when I release later versions of the hijacker, they will still run with the data from the earlier versions, and also, earlier versions of the hijacker will safely ignore any data intended for a later version of the hijacker. The hijacker also has a lot of potential to be re-used for other older games due to its flexibility. It is pretty much just a data loading workhorse that could be used to feed data to just about any game engine, as long as you can find/expand ROM and RAM. What it loads and where it loads it depend simply on programmer-defined "object id's" and "attibute id's". All of this in only 1.5K of code!
I hope to explain this all much better soon, I'm going to get together some source and docs for release soon, especially docs for the data format. but I'll need a place to put them.

Right now, I have switched gears to PC development of an editor to create the data structures that my hijacker consumes, since they do involve quite a bit of indirection and lend themselves to manipulation much more easily as treeviews and listviews than as assembler macros. :)

Well, we'll see how the weekend goes, I definitely have stuff ready to post soon.

Phoenix