There is some wacky bug with the inData() command.  (This is tested with the most recent version of Axe, 1.1.0, on a TI 84+SE running 2.43)

This code comes straight out of Detonate.  I'm sure it can be triggered in other situations as well, but this is how I ran into it.
I am using inData for a collision check with my explosions.  If you need to see more code than what I provide here, I can give that to you, but I think this should be sufficient:

Here's my code that should have worked, but didn't:

: 0->{T+L4}^r->{P+L5}^r
: !If inData(r3*16+r4+1->N,L4)
: !If inData(N,L5)
: N->{P+++L5-1}
: End
: End

The code inside the second !If would be skipped even if it was supposed to be executed on some occasions.  This code deals with bombs being detonated in my game, and sometimes the bombs wouldn't be set off, which happened if the second !If was erroneously skipped.  By adding more/less code at the beginning of my program I could change where the bomb would fail to be detonated, but I never saw a pattern.

This code, however, works, proving that it's an Axe bug and not my own code at fault:

: 0->{T+L4}^r->{P+L5}^r
: !If inData(r3*16+r4+1->N,L4)
: 0->{P+L5}^r
: !If inData(N,L5)
: N->{P+++L5-1}
: End
: End

Like I said, let me know if you need more info.  I can give you my source if you need it; it's no trouble at all.

Sorry to say it, but it is your code's fault. This line is the problem:

:0→{T+L₄}ʳ→{P+L₅}ʳ

The value left in hl after storing a number to a constant pointer is the original value you stored. But when storing a 2-byte number to a non-constant pointer, the value left in hl is pointer+1.

And now I feel really, really dumb.  I should have remembered to check that.
Thanks, Runer, and I'm glad to hear this isn't Axe's fault.

It's scary how unreadable optimized Axe can get.

I think in the process of fixing replacements in Axioms in 1.1.0, another bug was introduced. Now, if I reference an Axe command or another Axiom command in my Axiom, I get two copies of the referenced command in the compiled code.

Is it possible this bug could have other side effects?

Also, I've had a few problems with the instant goto.  I'd get err:parenthesis and goto.  Editing is fine, but once I quit some program or another will sometimes have an edited name (ie one time the archived program "SDOTRUN2" became SDOTRU►2").  thepenguin's archive cleaner fixes it, btw, but it's still kind of concerning..

This just happened again in Axe 1.1.1.  I can't get wabbitemu to replicate it, but it changed prgmSPRITES to prgmSPRITE► .  Evidently it's not just Err:Parenthesis, this time it happened on an Err:missing program.
The program whose name was corrupted was in the archive, btw.  I think it was the previous time, too.

Edit:  Just noticed this corruption is six letters into the program name as well.

when using files, the Y# has to be at the beginning of the statement.

Pt(x,y, 5+Y1) would fail, where
Pt(x,y, Y1+5) would work.

opps your right...  i use copy.

Copy(Y1+(B*3), L1 , 10) would work.
Copy(B*3+Y1, L1 , 10)  would fail, where