We don't know for sure, otherwise we'd already have posted weeks ago
Lua is no substitute for native code anyway.

Well, in fact, you can see already a few changes if you create a script with the new platform.apilevel (2.3) and dump _G (Lua's environment variable where "everything is").

For example, resources handlers etc.
These changes will be reflected by new features within the SDK (script editor in the computer software), though, so we'll have to wait for its release to actually see what's new...

Changes will be put on http://wiki.inspired-lua.org/Changes_in_OS_3.6 , by the way.

Of course, I am pretty sure that speed won't be improved, though. >.<

Images, in fact, are supposed to have been greatly improved (completely new system). I don't know about the rest. What's slow in Nspire-Lua is some graphing parts, not much else in fact.

Really? That's good then, but will it still be possible to set the program version to OS 3.1 or something?

Yep, that's still going to be possible. (and in fact, cross-version handling is now a fully-exposed feature within the SDK)

Also, I wonder if image size will be greatly reduced?

I haven't tried yet, but that's highly possible though, with the new thing (Could it be worse anyway ? )

We'll see

That gives a nice convenience tradeoff, though. The only reasonable change I can think of for that without making some kind of converter would be to switch to UTF-8 or plain ASCII.

UTF-8 has the full range of characters that UTF-16 provides. Special characters are larger, but normal Latin characters are only 1 byte each. UTF-16 is almost always 2 bytes per character, with only the most obscure character sets taking more. UTF-32 is ALWAYS 4 bytes.

All 3 have the same base character range, 4 bytes worth of individual characters. However, the worst case sizes are:

UTF-8: 4 or 6, depending on the standard used. (6 if using the pre-2003 standard, but 4 reduces the theoretical size)
UTF-16: 4 bytes, but the implementation makes this 4 have more chars available
UTF-32: 4 bytes (exact)

The best case, on the other hand, is much more telling:

UTF-8: 1 byte
UTF-16: 2 bytes
UTF-32: 4 bytes

Keep in mind, the unicode character set is far from full. The set is laid out sparsely, with several large gaps. The slight lackings in UTF-8 fall in these areas, giving it full access to all characters.

UTF-8 is used when dealing with memory constraints, and also when using common sense. It's also the newest standard. The primary disadvantages lie in problems with measuring length.
UTF-16 is the "old" way, having been around the longest of any Unicode standard, in many forms.
UTF-32 is nice for slow 32 bit systems, since it is straightforward to interpret. However, usually memory constraints outweigh this.

That's still better than the HP Prime format DJ was talking about, though. Pixels as raw bitmaps aren't that bad, especially in a sprite-based engine.