You mentioned that you're not pushing the block becasue of the physics involved, but won't you still need those physics anyway for releasing the cube in mid-air or dropping it though portals?

That's what comments are for  You should see Runer's Sprite Editor source, more than half of the size of the program was indents and comments.  That's another paradigm that BASIC programmers are too used to, commenting in the code doesn't affect the final executable at all since they are all ignored when compiling.  In BASIC however, its seen as wasteful since it becomes part of the program.

It sounds like you have the right idea.  Since L1-L6 are just numbers, it makes sense for the compiler to add/subtract/multiply/divide etc. to create a single number BEFORE parsing so that the program doesn't have to do it during runtime.  However, if you have any variables or non-constants then the compiler can not make this optimization and the size will increase.

Your 2 examples {L1+Z*4+12} and {Z*4+L1+12} would return different values as some people have said due to strict left-to-right order of operations.  However, I assume you are asking about the difference between {L1+(Z*4)+12} and {Z*4+L1+12} and in that case, YES, the second one is more optimized since L1 and 12 are combined to form a single number that will get added to the variable part.

You can use as many braces inside of braces as the stack can handle and yes, they act like parenthesis when you use them that way.  You can read from expressions with nested braces and store to them.  But of course, the less parenthesis you need, the more optimized it is.  If its possible try to put all that stuff at the front. {{L1+12}+L1+24} is more optimized than {L1+{L1+12}+24} for the reason above in addition to the fewer acting "parenthesis".

Floating points are just as slow as BASIC basically.  I did indeed make a Mandelbrot set program in assembly using the OS's floating point bcalls and it still took about 10 minutes to graph.  The only way I was able to graph the set with Axe Parser in under a minute was to use fixed point math instead of floating point math.  8.8 is really really fast and fits into a normal Axe Variable, however the resolution is low, you can't make the pixels any closer than .0039 apart (which is 1/256th) or else the image breaks down and pixelates.  You can increase the accuracy to 8.16 or 16.16 which are a little bit slower, but it would allow the pixels to have spacings as small as .000015.  If you're really daring, you can have an arbitrarily long fixed point number which is referenced by a pointer.  I'm going to be adding a new command soon that makes multiplication easier to do as soon as I can figure out an efficient way to do it.

You need to clear the Text Shadow, not just the LCD.  My guess is that you were using the ClrLCDFull command or something?  Use ClrScrnFull instead becasue that also clears the Text Shadow as well.

Oh wait, you're right    I must have accidentally clicked on the old copy.  I had both on my desktop.

Return IS ret in Axe.  They are one and the same

A self launching program is going to be too difficult without help from the OS or the start-up app.  What I would do instead is have the calculator turn off the LCD and then halt the execution until the next [ON] interrupt.  You might have to get an ASM programmer to write this for you if you're new to assembly since its pretty tricky.