I have another suggestion, This one I borrowed from Visual Basic.
Try
..some code
Catch
..errorhandling code
End try

The try-catch-end statement Tries to run the code, if it fails however the error is "catched" and can be handled appropiately. In Visual Basic one would do:
Try
..some code
Catch ex as Exception
..errorhandling code
End Try
However for OTBasic I'd just do "Catch" instead of "Catch ex as Exception" or worse "Catch System.Diagnostics.Rightrestrictions as Exception" (< that is not a real error btw). Also "End Try" can be "End". The use of this is that you can safely test code and use code that might not work on every calc. Say a user has for some reason restricted rights on a calc and A program does a function/command or whatever that falls outside those rights, then the user would get a message saying what the problem was, thanks to try-catch-end.
I think it is specifically handy for programs or routines that are prone to errors. Since I assume there is a implented break function to prevent (like we have now, the on that prevents RAM clears) it might be less useful. It really depends on how the OS is programmed and if there is something like 'rights' cause then it's useful.

Edit1:
For the Language Design section: How about a undo/redo function? So if you accidentally hit clear you can still get your line back. I would make the redo's/undo's limited though to keep memory usage low. Maybe even auto-backupping when enabled? (for the paranoid amongst us)
Edit2:
I Have no clue whatsoever how the KOS GUI is gonna look like but maybe we could implent some of it's GUI elements (e.g. Button, Label, WindowForm (once again I dunno if these will actually exist, just saying)) make them callable as drawing functions. This could however be also a external "package" which brings me to my next idea. Making the langauge 'package' compatible. With that I mean that certain commands can be added via a package. This package contains the tokens for the commands and KOS compatible routines to run them. This way users can extend the langauge to their likingning.
Edit3:
Another conditional structure I'd like to see is this one (which I borrowed from batch):
If Exists sString
..do something
End
This tests whether string String exists or not. This can be useful to say, have user able to remove a game but to save the game data/save game. With one check you could then easily see if there was any saved that and act appropiately. I think this is very, very useful!

Possible would be having a non-token based system, or have it only use tokens internally, and not for editing.
String routines would be cool.

Like the MATH menu on the TI-84, not the apps menu: there is an up and down dimension, and left and right (in a program).

I think matthias1992 suggest an "IfExists" for that, but bumping it is fine

Your idea would be great, except that the programs that use the libraries would not be compatible with someone that doesn't have the libraries. I think that these libraries should be automatically included in the OS, but you should need an external application to access them (just like the extra variables on the TI-84).

Sounds good.
program4: The solution to that is to package the library with the program, and perhaps give the device a central libraries location. If the libraries the program needs are already there, you can just have the device discard the extra copies.

Exactly. Whenever you do something like: UseLib([LibName]) it knows it has to send/include the library as well. I like the central libraries Idea alot. Just like you had apps on the original TI-8x you can now have a same sort of place for packages and libraries. That would be pretty awesome . Imagine a 3Dlibrary being created, you can then in OTBasic do 3D stuff with poly's and so! That is because every library is programmed in assembly so it runs real fast! That would be pretty awesome right?

You sorta reminded me of the never-used OpenLib( and ExecLib( commands on the 84+(SE).
Though libraries would actually be libraries and not stand-alone apps
Although this is more of a device suggestion than BASIC language suggestion, will there be folders? I'm assuming yes, since you plan to use KOS or something similar. Maybe a /libs folder for everything library-related.

I believe there attemtps/plans at making a FAT like filesystem but I can't tell for sure. Would be great though. I never really understood OpenLib() and ExecLib().

I just thought of some more commands we might want to include namely random number generators and sorting commands (to sort lists but maybe also to sort strings?? (migh be useful when delimiting))

any ideas on that?