I actually wouldn't mind having that, even if it took extra space. Since I have an 84 se, space isn't really an issue for me. I know that it is for some people though. Perhaps two different AXE versions could be made, one being the normal, and the other having this and other memory hogging features.

Two Axe releases in two days?? That must be a record!!

Nice update though and I'm glad bugs are slowly getting narrowed down.

The new speedy compile option disables peephole optimizations. This should result in the parsing of average code being about two times faster while producing compiled code that is about 1-5% larger. It's very useful for recompiling large projects after making small changes for testing purposes, but remember to compile the slow way for your project releases!

Yeah, all the new zoom option does is disable the peephole optimizations, which makes it both slower and larger (but only slightly).  As Runer suggested, its really only for testing purposes in large programs that otherwise take a really long time to compile.

I'm just getting started with the more major peephole optimizations.  Some optimizations, like for instance 2->A:{A+L1}->B now automatically optimize to {2->A+L1}->B , which should help make code more readable.  The fact that finding optimizations like this is getting significantly harder to do in the disassembly means that Axe is inching closer and closer to the ASM limit.

I've finally figured out how to easily and intuitively allow stack usage for Axe programs that's so easy, even beginners can do it  

Its so simple, I don't know why I didn't think about it before.  The syntax will simply be "keep(EXP1,EXP2)".  All it does is evaluate expression2 and then return expression1.  You might be like "Wait, what?  That seems so pointless, why can't I just do EXP2:EXP1 then?  Isn't that the same thing?"  The answer is no.

Consider this:
A->B:B->A
In that example, first, A is stored to B and then B is stored back to A again.  Not useful at all.
But now consider this:
keep(B,A->B)->A
What happens now?  You might think that since keep returns the first expression B and then stores it to A that its still the same piece of code. But no!  Keep evaluates B first and then keeps that value until the end of the keep.  So even though B changed value during the 2nd argument, the original B is returned and stored into A.  In other words, this is how you perform an exchange with only 2 variables, and its 4 bytes smaller than using an extra one too!

So where is the original value of B stored then?  That's what the stack is, but you don't need to know that.  All you need to know is that keep is magical and super efficient for this kind of thing.

EDIT: OOOOH, I just realized you can also make recursive function calls with this! 
:Lbl FUN
:keep(r1,keep(r2,FUN(r1,r2)->r3)->r2)->r1
:Return r3

That seems like a pretty good way to safely implement stack usage. But could there also be commands for more experienced coders that simply equate to push hl, pop hl, and ex (sp),hl? Because your idea is great for casual coders, but crazy people like me like to be able to squeeze every last byte out of code. Something like you suggested here seems to be a good idea for syntax, and calc84maniac suggested a good syntax for ex (sp),hl here. Of course you would want to warn users about the dangers of these commands in the command list, but I don't think it's too dangerous to warrant not adding. There are so many other ways a programmer can crash their calculator with Axe, adding a new one won't really change much.

That seems like a pretty good way to safely implement stack usage. But could there also be commands for more experienced coders that simply equate to push hl, pop hl, and ex (sp),hl? Because your idea is great for casual coders, but crazy people like me like to be able to squeeze every last byte out of code. Something like you suggested here seems to be a good idea for syntax, and calc84maniac suggested a good syntax for ex (sp),hl here. Of course you would want to warn users about the dangers of these commands in the command list, but I don't think it's too dangerous to warrant not adding. There are so many other ways a programmer can crash their calculator with Axe, adding a new one won't really change much.

I second that. I've been wanting more access to the stack for a while now.

That seems like a pretty good way to safely implement stack usage. But could there also be commands for more experienced coders that simply equate to push hl, pop hl, and ex (sp),hl? Because your idea is great for casual coders, but crazy people like me like to be able to squeeze every last byte out of code. Something like you suggested here seems to be a good idea for syntax, and calc84maniac suggested a good syntax for ex (sp),hl here. Of course you would want to warn users about the dangers of these commands in the command list, but I don't think it's too dangerous to warrant not adding. There are so many other ways a programmer can crash their calculator with Axe, adding a new one won't really change much.

Directly using pushing/popping can definitely cause problems in the middle of expressions, and in For(const) loops for example. There are too many things subject to change in the implementation of Axe for direct stack access not to be potentially buggy unless you know a lot about the inner workings of Axe. I think Asm() will suffice for crazy hackage.

Edit: Well, I suppose Axe could keep track of all pushes/pops as well as which ones are manual and which ones are internal. It could then error if it tries to internally pop a manual push or manually pop an internal push. That's fairly safe, I guess.