The problem is, is that the z80 is a 16bit processor by nature, and consequently doing anything with a bit length greater than 16 require a lot more custom code. 

Feature request: ouput symbol table? It's a little obscure, but I don't think it'd be too hard to implement; right? (One use could be for calling app routines from an external program.) As an option, the compiler could (after compilation) output as axe source named constants/variables all the label address offsets and static pointer locations. I know there's not a lot of room left in the app but...

It's more of a compiler feature than a programming feature. Basically, I'm asking for the option to be able to see the addresses of all the symbols in the source (that is, labels and static pointers like GDB1). The compiler already has to keep track of them all, so I'm hoping it's not too hard to finagle an output file somehow (or even display in the compilation screen).

The main reason I can think of is if you want an application to have routines that can be called from an external program, but in that case you should really be using a jump table anyways, and I think it's simple enough to figure out where that would start in an application.

Or he can use this

i know, this is bumping a old feature wish, but i'm doing it as it is now back into development (axe)
so
Multi-page apps!
Everything is stored into page one
exept
[DATA]->nGDB1 is stored in page n, if n is not specified it stores on page 1, so the other pages are only data, do you get what i mean?

Heya and welcome here

And yeah about 2 this can be difficult to test multiplayer games. I myself am lucky because I know one person IRL that was into calc stuff at one point and actually frequents the forums here, but otherwise that can be hard. However this might be kinda hard to implement

I have one suggestion for future Axe versions too by the way (even though I don't code anymore): An option to disable progress bars when compiling. Since they were added, Axe seems to take an incredibly long while to compile anything (like 5 times longer).

Supersonic Ball:
Axe 1.1.0: 6 seconds (final version with no progress bar)
Axe 1.1.2: 9 seconds
Axe 1.2.1a: 8 seconds (Note that I tried this version after writing this post and noticed the slight speed improvement)


EDIT: It turns out that the speed was improved by 1 seconds at least in the latest version and that most of the speed decrease was due to Axe compiling being more and more complex. Because Axe 0.2.6 compiles Supersonic Ball in 1 second.

I'm probably a crazy person. so please ignore this if I am one of those. The first pass I guess is where it converts it into assembler, and then the second is optimizations? Something I'd like is for it do another pass of peephole optimizations, but make it non-default so that if someone's crazy/really needs whatever additional  little things it can do, it'd be added, by holding some button, like Mode when compiling to make it do another round of optimizing/shrinking. Other than that, that's all that I can think of right now as far as my "would like to see" list. Also, I imagine that Axe is already using the "full" 15mhz on the ti-84s, but if it isn't, I'd love for it to start using it. I imagine it is(as the compile times are rather quick, for everything I've tested/wrote), but if not I'd love for it to be there.

One other thing that I'd love to have is for it to have the subroutines be able to return a value as the built in functions of the calculator/axe ones do. As this'd help make my code a tad bit more clean, there's already the option of giving subroutines variables, but being able to return one would be uber-awesome. I'm not even talking about passing around ptrs with mass amounts of memory, just some way to return a 2byte value would be uber-awesome/useful for people like me who are used to c.

I'm probably a crazy person. so please ignore this if I am one of those. The first pass I guess is where it converts it into assembler, and then the second is optimizations? Something I'd like is for it do another pass of peephole optimizations, but make it non-default so that if someone's crazy/really needs whatever additional  little things it can do, it'd be added, by holding some button, like Mode when compiling to make it do another round of optimizing/shrinking. Other than that, that's all that I can think of right now as far as my "would like to see" list. Also, I imagine that Axe is already using the "full" 15mhz on the ti-84s, but if it isn't, I'd love for it to start using it. I imagine it is(as the compile times are rather quick, for everything I've tested/wrote), but if not I'd love for it to be there.

As Sorunome said, there is already a peephole optimizer. There is also the function #ExprOn if you really want to save space.
Axe uses 15 MHz when compiling on capable models, and if you want to use it in your progs, use Full.

One other thing that I'd love to have is for it to have the subroutines be able to return a value as the built in functions of the calculator/axe ones do. As this'd help make my code a tad bit more clean, there's already the option of giving subroutines variables, but being able to return one would be uber-awesome. I'm not even talking about passing around ptrs with mass amounts of memory, just some way to return a 2byte value would be uber-awesome/useful for people like me who are used to c.

Your routines always return a value but you don't know that. In short, they return the value of the last calculus.
Example, try writing this:
1
+2
→A
*2
→B
Then, you have 1+2 in A and A*2 in B, because this is in fact like this:
1
Ans+2
Ans→A
Ans*2
Ans→B
where "Ans" is the 16 bit register hl (and you can compress your code to 1+2→A*2→B).

So if you want your routine to return a value, just do something like that:

.code here
Routine()
→A
.code here

Lbl Routine
.code here
B
Return

Then your routine will return the value of B. Of course, instead of B, you can put r1*2+4 or 8, and instead of →A after the routine, you can put *4→F or i don't know, but what you asked for is already possible.