sorry, but what do you mean by single character operators?  and the main reason I'd want to change the syntax is because otherwise I'd have to change a ton of source for my program, and its harder to get to the new and/or/xor characters

Just a thought:

IIRC, Axe compiles all the code and skips all the data on the first pass. Then, on the second pass, it appends all the data to the end of the compiled program, creating space as it sees fit. What if these commands were made:

FnOn -  Activate BASIC command mode.
FnOff - Deactivate BASIC command mode.

Here's where my idea comes in.
What if Axe made three passes? The first pass would check to see if there are any FnOn or FnOff commands in the program, skipping everything else. The second and third passes would be the normal Axe compilation.

For example:

First Pass:
Check for any FnOn and FnOff commands. If so, save that line and skip over all code until the end of the program is reached or the FnOff command is reached.

Second Pass:
Compile programs.

Third Pass:
Append data.

So, penultimately, the program code is the ASM version of this.

:Asm(prgmAXE1
:<TI-BASIC code>
:Asm(prgmAXE2
 

tl;dr: Axe should compile subroutines and insert them into a large ASM program if BASIC commands are possible.

Of course, all of this is useless if Quigibo figures out a way to reuse commands for different purposes.

Interesting.
How will hybrid programs be handled?

Also...

The idea of custom fonts was brought up. [Personally, I think it would be very memory-intensive.]

This as well as the idea of sprite rotation by any angle. [I think that was brought up before...]

Also, SortA(), SortA()^r, SortD(), SortD()^r.

Yeah, I've got that working already now, except there's a really weird bug I'm trying to fix.  The actual sort routine is very small and fast, its only 21 bytes and sorts a 256 element list in about 1/4 of a second in 6MHz mode.  I'll probably make it larger though to handle sizes greater than 256.  I'm using insertion sort.

By the way, the main focus of the next version will be on variables.  I already have Ans saving and loading working, I expect to have strings, real variables, Picture files, and other things like that all readable and writable.  And I'm also going to add the ability to create programs.  It's possible some existing syntax might change but that seems unlikely at the moment.

Don't know yet, but I haven't started optimizing the parser itself, so I think I can make it small enough to fit on one page, at least for the next couple updates.  Probably 0.3 will be the time when I switch to a 2 page app.  However, the parser will not be larger than 2 pages at any point.  If I want to add a suite of helper programs, I will add it as a separate optional app.

The TI-Basic variables, if I understand it correctly

Probably the same way appvars are: with storage into strings.
You'll have to ask quigibo for how he actually plans to do it, but it seems you'd have something like:
"Str8"->Str1
If GetCalc(Str1)->X
{X-2}^r->S
X+S-1->E
For(A,X,E
Disp {A}->Frac
End
End
Disp i
Which would display Str8's contents on the homescreen, or nothing if non-existent/archived.