You absolutely need to add 15 MHz mode!
Compatibility isn't really a problem, if somebody really needs to make it work on the 8 MHz one,he could have 2 versions or a frame skip option...

By the way, I added a 15MHz mode in the next version and its incredible!  Why didn't I know about this when making pyoro?  I could've had 8 level grayscale or something!  But the downside is that if you use this mode, your games will run 3 times slower with an 83+ than with the other calculators so compatibility becomes an issue.

Can we chose to have 6mhz if we want?  This would allow games to run the same, when speed is not an issue.

Could we do something like
.6MHZ
and
.15MHZ
to control the speed at the beginning?

I've already added it, this is how it works.  You will use the command "Full" found in the modes page and it stands for full speed mode.  However, the command also returns a value.  It will be false (zero) if the calculator does not support 15MHz and true (non-zero) if it does.  So if you had a game you only wanted to be able to run on 15MHz calcs, you can do this:

:!If Full
:Return
:End

That would quit the game if the Full command failed.  If you don't care about the type of calc, then you just use it normally like this:

:Full

The command "Normal" returns to regular speed and doesn't return a value since it can never fail.

Awesome!
I can't wait for 0.0.7...

I think the above way you just wrote is better.  Having a different program for each type of calculator is more annoying in my opinion than a single, insignificantly larger program that works for every calculator.  I might add a command that returns the exact type of calculator and operating system version, not just 15MHz support.

That's kind of what I had in mind. We could use .If .Else .End and such fir that. How about also adding variables that the compiler uses? Like .VER would return te version of the device that it was compiled on? That would make some more nice little modifications to code possible. Also a Date one would work too so it would tell you what date it was compiled on (of course that would be 15MHZ only). 

I was also wondering if you could add a third back-buffer, or have a buffer in the program (so like have a blank splash screen in the program that we can edit/read , although you would have to put checks in place so we don't accidentally corrupt the program with overflow from it)

That would be very useful as well.  This made me thinking, since the LCD isn't memory mapped (right? ) swapping buffers would be as simple as changing a pointer in the safeCopy routine right?  Or do I not know what I am talking about?

That's actually a really good idea to use some variables as variable pointers that are looked up by some routines.  Maybe I will use the "u" "v" "w" variables for this since I'll probably need more than 1 of them.  The only problem with this is that the variables have to be initialized before the program starts.  Otherwise, it will just be something random.  The parser could do it automatically, but then its just adding extra bytes in case you decide to change it again to anything but the default.  It would be really annoying to start every program with L6->u to do any drawing and it might not make sense for beginners.

I could always make the variable location part of the self modifying code so it already starts initialized without using extra memory, but then that means it can never compile as an app.  Although I'm still not sure how feasible it is to compile apps on-calc.  Have other programmers been able to do it?

All those precompile headers use variables that have to be set somewhere.  That means I would also need preprossesor variables which would be very difficult to add and I'm already running out of memory.  There is no reason that the same program should compile differently on different calculators since only the executable would be distributed ideally.