This is something i just created like 5 min ago after a brainwave over the problem i have been having with Portal.  A long time ago i envisioned Portal as a large program that copied data around so that it never exceeded the code limit, but this was impossible because of absolute jumps and calls, and because the code was so changing that counting the bytes was impossible. 

But what if the program was page based, and i don't mean like RAM pages, but virtual pages.  Each page would be a separate program, compiled separately so that each one of them was compiled to be executed at $9D95.  Each program page would be the same length as all of the others, and so swapping them would be easy.  The only thing needed is a way for the swap to happen without messing with the current execution.  For this i have created a custom header for every program to be included, as a common space where the swapping happens.  There is also a program that takes multiple programs as input and outputs a program that contains all of the programs compiled into 1.

Any program can switch to any of the other programs at any time.  Simply by following the following syntax. #Goto SWP, where # is the program page they want to jump to.  SWP is a label that is inside of the included header, that performs the swap and execution handling, which is actually quite simple. After the swap happens, execution resumes as normal from the beginning of that page and program.  Return still brings you back to the homescreen, and all OS calls behave the same.  You can have as many pages as can fit in RAM, and they can be any size, as long as each page themselves don't exceed the code limit.

I will release the code in a sec after i create a user friendly generator to combine programs, because as of right now it only works with 2 programs named P1 and P2.

They can be whatever size you want, although the max is around 8800 because of the code limit. 

Alright, so i have created the combining program.  It takes arguments from Ans, Str1, and Str2:

Ans: The size of the pages
Str2: The name of the program to combine into.
Str1: List of all the programs to be combined, in the order to be combined.  Must be padded with spaces up to 8 characters.  Eg: "I_______LOST____THE_____GAME____" If any of the programs have a file size larger than the page size, it will throw an error.  If any of the programs are archived or nonexistant, it will throw an error.  If the String is not a length divisible by 8 it will throw an error.  If neither of the strings exist, it will throw an error.

All the programs being combined must be compiled Axe programs with the included program INC as the first line on the program.  If it is not the first program, it will throw a HEADER error.  To Jump to a page, use #Goto SWP.  Which will swap page # with the current page.  Note that execution always stays on page 0, but by swapping to page 1, page 1 becomes page 0 and page 0 becomes page 1.  To swap *back* to the original page, you would swap with page 1 again.

Included Programs:
ThetaCombine: The assembly combiner program
ZCOmbine: A basic program that sets up and runs the combiner program
P1: A sample Axe code using page swapping
P2: Another Axe source meant to be used with P1
Axe1: Compiled of P1
Axe2: Compiled of P2
Inc: The include program
A: The source to ThetaCombine

They cannot be archived unfortunately, as they are only virtual pages and actually all part of the same program.  Note that i encountered an error in Wabbit regarding getting header errors but its not happening on my calc.... hmmm

EDIT: Well i can't seem to find the issue, so its probably not working for now, i have to go but i will check back later.

EDIT2: I fixed everything hopefully ^^ Everything works as planned But now if you don't put a header you will clear ram You can also put things in front of the header now, just note that when you page swap, you will swap to directly after the header (the INC file)

Well here is how i am going to use this for PortalX, there will be several pages with several purposes

Page1: Main Menu code, special code for special rooms
Page2: Level Data, Level Loading, Transition Animations
Page3: Engine

It would start on page 1, then jump to page to to load the level, then quickly swap to page 3 while ingame.  If you quit, swap back to page 1 for menu.  If you advance to the next room, swap to page 2 for transition and loading the next level.  You wouldn't need a copy of each piece of code for each page because you can swap to the essential piece of code whenever you need to run it.  

EDIT: And the purpose is because of Absolute jumps.  When you compile a program, it is meant to run at a certain address.  If you try to move it, it will crash rather spectacularly.  Well moving the programs is exactly what this does, so the programs need to be compiled to run at the start address (which is where they are being copied) and the only way to do this is compile them separately.  Does that answer your question?

EDIT: And the purpose is because of Absolute jumps.  When you compile a program, it is meant to run at a certain address.  If you try to move it, it will crash rather spectacularly.  Well moving the programs is exactly what this does, so the programs need to be compiled to run at the start address (which is where they are being copied) and the only way to do this is compile them separately.  Does that answer your question?

Axe could use a "ReOrg" command.

This looks like a nice alternative Builderboy.  Nice job.

I guess I could see how cutscenes might work, although all the sprites and graphics used in the actual game that are also used in the cutscene would need to be copied into the main page as well. And say you wanted the last level to be like the GLaDOS battle. You're still playing Portal during the battle, so you would need the main engine. But GLaDOS then needs to be able to do it's own thing while you're playing the normal game.

Since you posted this, I've been thinking about it over and over, and with a few routines I'll ask for elsewhere, I could quite possibly use this to rewrite Nostalgia.

The way it's currently set up, I'd need quite a lot of optimization to get it to fit in an app. However, with this, I could theoretically have several archived appvars holding the code for each multi-paged program. Then, I could copy that data to a program and execute it from the app. When I needed something that didn't exist in the pages of the current program, I would jump back to the app and switch the program by copying the code from another appvar.  All my data could remain in appvars like it is now, and I would definitely fit within the executable code limit in the app.

Of course, this is all 100% theoretical, and I haven't tested the idea at all yet, but if I can get a routine to execute a nostub program from an app, I'm gonna test it.