Actually, that's something I can fix.  I haven't updated the token replacement chart for ages since no one's requested any new ones.  I'll see what I can do for the next update.

Ah yes I found it thanks.  I was storing the "Is File" boolean in a variable instead of the operator stack and that made file references non-nestable.  I'll have that fixed next version.

Just wanted to give everyone a quick update on progress.

This is day 6 of the rewrite.  I can now parse simple programs and have data, labels, variables, and gotos working correctly.  Though I still need to rewrite subs, interrupts, internal subroutines, and axioms.  So currently, I cannot compile any large programs, but I'm almost at the point where I can.  There is at least one extra MAJOR convenience feature that was requested a long time ago that will finally make it to the update, but I won't spoil what it is yet. I still have no idea when it'll be finished because of all the inevitable unexpected issues to come, but hopefully before the end of the month.

Reading labels as values is for sure coming in the next version.  But its mostly for Axioms that require labels as arguments because there really isn't any other use for them since you still can't jump to arbitrary values due to leaks and unsafe code.  I think I might have a way to allow programs to exit anywhere soon, but I already have to rewrite half of the parser from scratch so I doubt I'll have time next version.

For those other assembly commands, most of them are really too specific and low level for any general use.  Runer112 actually made an LCD Axiom LCD Kit that does most of those already and you could certainly design a port axiom to allow arbitrary port writing, I just don't see the purpose of that for the average game.

It could be related to Crabcake if you're using that.  I'm not sure how it works exactly, but its possible it could be conflicting with the archive reading commands since the memory mapping is different.

Oh yeah, I forgot to mention that!  Bit 3 controls if auto backups should be turned on or not when using the CompileOP1 entry point.  Axe always saves the current setting configuration when it exits so if you want it to restore the original settings, you'd have to read and then modify the Axe appvar, which contains a single byte: the setting.  Maybe I'll change that for 1.0.0 though since I see how that can be annoying.

That includes sprites too though.  You can't do:

Pic1+8->Pic2
Pt-On(0,0,Pic2)
[]->Pic1

However, you could do:

Pt-On(0,0,Pic2)
[]->Pic1
Pic1+8->Pic2

And you can always declare the sprite first like Axe has been doing so far:

[]->Pic1
Pic1+8->Pic2
Pt-On(0,0,Pic2)

Would it be possible to chain variable declarations, like:
L₁->^oMyVar1+2->^oMyVar2+1->^oMyVar3

Would make it a lot easier to change the size of a variable or add/remove variables during development.

Ooo!  That's a cool idea.  You can definitely chain them line-to-line but I'll see if I can add it all on the same line.