@monte: Yes there is more work to do here, and it will take a while.
As it turns out there is a lot you can do and indeed we have done where new behavior is a superset of the old. Unicode would be a good example. Stacks being allowed as references in behaviors is another (this should be coming in 6.7.4-rc-2 and 7.0.4-rc-2 - it is already on develop). One of the problems has been that the engine has long been written without regard for strictness - i.e. throwing an error in all cases which have not been explicitly enumerated. (We aren't making the same mistake with LCB - in that world if in doubt we have gone for the most-strict definition and error out in all other cases, thus leaving open a much greater degree of easier evolution in the future).
Whilst I see what you are saying about getProp/setProp unfortunately it has been part of documentation and 'common-law' that you use a certain pattern to do a certain thing with custom properties for more than a decade. Yes changing it might solve other bugs related to the triggers not firing if lock messages is true and that is all well and good, but the change will for 100% certainty introduce a critical unavoidable recursion lock-out in the cases lock messages / unlock messages have been used to access the custom property store of an object in an ancestor object (the example posted on the related thread). Clearly proposed behavior is not a superset of old behavior (and indeed this is the most vexatious case because it really cause scripts which use the current pattern to lock-up if the behavior changes), and the new behavior has an incredibly unpleasant possible side-effect when run against existing code.
I do need to do some more thinking on the caseSensitive in array thing - I'm still not sure even with that idea that arrays are well enough defined. We are trying to model several distinct types of data structure with a single generic syntax here which is the problem (untypedness is nice, but does cause headaches at times) - and the question is how to ensure the engine can make the right choice in context. Really you want the array's type to be inferable from the type of the keys used to build it - but there's a problem there due to the varying ways strings can be compared (its not just caseSensitive, in the Unicode world you have formSensitive as well).
revXML is the case of making it so that rather than returning UTF-8 as native strings, the APIs should be returning abstract Unicode strings (i.e. native of UTF-16 internally as appropriate). At the moment you have to write explicit code to do conversions of the UTF-8 if you want to do text-related processing. We can easily add Unicode suffixed versions (and no doubt will), but it would be nice if there was a flag which meant you could use non-suffixed APIs but still get the Unicode behavior (after all, if you are writing new code against 7.0+ then having to append Unicode to your API calls seems a little redundent!).
revDB is similar. It is about changing the revDB APIs so that it does the mapping from the database's internal charset for a column to an abstract string for you. Its very similar to revXML in that we can easily add 'Unicode' suffixes, but ideally you wouldn't have to use those in new code.
In the array <-> string case, what I mean here is that when you try to pass an array to string context, or a string to an array context then you should get an error. At the moment the conversion is to empty in both directions which hides bugs and unhandled corner cases in code. It doesn't affect what values you can put into variables - just whether or not a type conversion is an error.
the result being local: The current global nature of 'the result' is, quite frankly, an aberration which helps no-one. It is an impediment to readability, correctness, analysis and optimization. Also if one wants multi-threadedness at some point it ceases to become global anymore, it has to be thread-local at the very least with the performance overhead that entails. It is also incredibly fragile - some commands in the engine set the result, some don't - if one doesn't now but it starts to in the future it breaks code; if you unwittingly insert a command in a handler which does set the result, or if you add a return statement to handler which is used in a context where a handler does not expect it to be set, your code breaks. A much better semantic is the one in LCB - 'the result' is always the value returned by the previously executed command, if the command did not return a result then it is empty. It is an entirely local phenomenon with no possible side-effects beyond two side-by-side commands. (Note that local result and global result written scripts can live side-by-side - when going from local result script -> global result script, you just set the global result; local result script would never touch the global result).
error handling unification: Yep - this is a biggy. The refactoring makes it a much easier project to start looking at undertaking, but there is still a fair bit of engine legwork to do.
In terms of the example of introducing new keywords causing backwards compatibility issues - then, yes, that is true... But then we are very very clear and always have been - do not use English words for your variables as your scripts might break in the future. This is why we try to encourage people as far as possible to use variable prefixes, as it almost completely eliminates the problem (tExt being an example case it doesn't catch!). (Of course this problem would be completely solved by removing case-insensitivity from the syntax - i.e. all keywords must be lower-case, all variables and handler names must contain a capital letter - I'll perhaps not propose this as an 'anomaly' though, not yet at least