The ability to define Constants in terms of other constants.
For example, I would like to be able to do
L1+256->GDB1
GDB1+256->GDB2
Currently, that is not valid code. Can it please be made so?

It's actually very helpful for code readability in some circumstances.  I remember using this before in C++.

Freyaday, that is most definitely valid code. Are you sure you've tested this with the latest version of Axe? Because I did and it worked just fine for me.

Huh. Guess I was doing something else wrong.

I have a small feature wish right here!  Currently the percent completed meter can be meaningless if you have several included files in your program, the percent complete just seems to show random numbers because it's switching so fast.  Cal84 suggested it might be a good idea to have the percent compiled for included programs separate from the percent compiled for the main program (maybe not even include it at all?)  Perhaps directly to the right of the main percent, there could be a second percent when parsing included programs?  Just a suggestion

That's actually impossible because Axe doesn't know how large a program is when you have included programs.  It only knows the number of bytes read from the source as a percent of the total number of bytes.  There is no way I'd be able to calculate the expanded size unless I made a 3rd pass to do nothing but sum up the size of all the source programs recursively.  Alternatively, I could do that in the first pass so that the percent would be accurate during the 2nd pass, but most errors are caught in the first.

What I probably will end up doing is adding the name of the current program being parsed to the progress so the percent means something; the progress within the current file.

 how about making an option to display the final size of the program after compilation?
It would require a keypress at the end if the option is on, but it would be much faster than scrolling through all your programs in the memory menu.

Two feature requests:

• The ability to include token strings as data. I thought about a possible syntax for this, and I came up with ["String goes here"]. Perhaps there's a better syntax, but that's just what I came up with.
  
  
• A peephole optimization to remove instances of inc hl \ dec hl. It is very common for operations that return a boolean to end in sbc hl,hl \ inc hl, but in many cases, the inc hl to normalize the result to 0 or 1 isn't really necessary and returning a value of -1 or 0 would work just as well (sometimes better, as is the case with a piece of code I was just working on). Being able to add a minus one after the boolean operation to save a byte could be very handy and could definitely add up.

Yeah, I saw your FP math Axiom and I figured that being able to enter token strings would make it about 100x simpler. People could then just enter standard homescreen/TI-BASIC code which could be executed simply with a bit of setup and calling the OS to handle parsing it from there.