ok, so this isn't really a bug, but it's a warning...if you run this code:[0011223344556677]->pic1
7->D
For(C,0,50)
D+1->D
If D=8
0->D
End
For(A,0,12)
For(B,0,7)
pt-on(A*8[+D],A*8+D,pic1
End
End
DispGraph
End(note: [+D] is optional (take out the [] ))
you will with the extra +D on the completion of the program if you go to a menu and then back to homescreen your cursor will change to a insert-2nd one, and then your calc will crash and ram clear, if you exclude the extra +D then you will brick your calc...the same thing happens but instead of a insert-2nd cursor it is a lowercase-alpha cursor. and your calc will not crash but stay on that screen, and I tried pulling the batteries (all of the AAA's) out to no avail.
I was able to fix it though by linking a classmate's 84+ to mine and sending an empty L1 to my 83+, and upon the 84+ erroring because there was nothing receiving, my 83+ on the other-hand unfroze and I was able to do things with it, although the alpha cursor was stuck on lowercase... when I didn't try to clear the ram right away it froze again, and I had to send L1 again. the second time I immediately cleared my RAM and my calc is now fixed.

tl-dr;
don't display sprites off of the screen on the bottom, or to the right by 8 and then quit out of the program, bad things happen...

yeah, I figured that out...and wow that was some bad corruption

Most definetaly, as of now in the program i'm writing i needed to take super special extra care that the object didn't go one pixel off the screen, and there are going to be cases where you are going to want that anyway, like for smoothscrolling maps and such

Wow. 
So far I've cleared my ram twice (infinite loops, pulled battery) and corrupted a group with Axe (but I have no idea how). 

I'm liking Axe, but not the annoying glitches.  Axe is still awesome!

You guys all complain about "RAM clears" and "corrupted memory".  Have you ever tried to program in assembly?  There are so many leaks and corruptions that happen, not to mention all the frustration of trying to find logical errors in the code, that almost all ASM programmers run their works in progress on emulators just in case and to speed up the process.  I can guarantee that if you tried to make the same program in assembly (unless you're highly experienced with it), you would have had at least an order of magnitude more problems with the code.

Remember, me giving you the freedom to run lower level assembly code and commands is a trade-off with the safety of running it.

Now, if you get an unexpected error either at compile time or at run time, I really need to know about that so I can fix it.  I currently am aware of 2 mysterious bugs.  One is that the compiler sometimes gives a random error if the program was just modified but parsing a second time always works.  I have no idea what is causing that.  Another error mysteriously vanished when I added some code unrelated to the error, so it will probably come back to haunt me sometime.  I think it had something to do with automatic parenthesis in math operations.

Ug...tell me about it...I had some of the worst memory leaks on hunt, and it took me forever to fix them
the random error tat isn't an error usually comes up with me if prgmLOL is exsisting, so deleting it before compiling will usually keep it from happening, but sometimes it won't.
Hmm, how hard would it be to add something that when it errors it tells you what line it's on?

You guys all complain about "RAM clears" and "corrupted memory".  Have you ever tried to program in assembly?  There are so many leaks and corruptions that happen, not to mention all the frustration of trying to find logical errors in the code, that almost all ASM programmers run their works in progress on emulators just in case and to speed up the process.  I can guarantee that if you tried to make the same program in assembly (unless you're highly experienced with it), you would have had at least an order of magnitude more problems with the code.

Remember, me giving you the freedom to run lower level assembly code and commands is a trade-off with the safety of running it.

Oh I do know in ASM it is worse. I did not code it, but I do know in ASM you have direct access to the calc memory, thus easier to break stuff. It is even possible to delete the calc OS sending certificate IIRC, causing it to no longer be able to receive a new OS anymore, so if your OS gets deleted, your calc is bricked for good. However we still have a right to complain as lib-enhanced BASIC/other languages programmers because in our case, we program directly on the machine the program is gonna be tested on, meaning that unlike you, if our program crashes, we lose everything we didn't backup. It may be much easier for us to debug these errors, but at least on your side you don't have to backup your progress everytime they happen. In BASIC we also have to cope with rare TI-OS bugs that causes some BASIC programs to behave weirdly for absurd reasons (such as lone If statements inside a For( loop that doesn't have its closing parhentesis or when storing a very large set of concatened strings in one STO command). Fortunately, in pure-BASIC we no longer have to deal with extremly bad OS bugs that can cause RAM Clears such as when having a large PRGM list on OS 1.13 and the Equ>String glitch.