As for Protopia's command about preserving backwards compatibility, a lot of people have different ideas of what should be preserved, and what can be discarded.
There are probably as many different views about backwards compatibility as there are people expressing them, but in the end someone has to make a decision, and hopefully make them in a consistent, thought through way over time. Whilst many of us may have different views about how we would handle it if we were making these decisions, Khaled is the developer and the choices are his to make and his to own the responsibility for the consequences - and I fully support him in this regardless of whether I would make the same decisions myself.
However it appears that I need to apologise for not having explained myself clearly.
1. The "legacy" script engine would maintain backwards compatibility in the exact way that Khaled has maintained it for all these decades - when using the "legacy" engine,
$read would
not "halt the script with an error that displays a message pointing them to /help for the fix" as tat would break the script and be backward incompatible. Instead it would log a message to the custom window/log file detailing the issue and what would need to be changed to fix it so that the code would work in the "clean" engine. It might even actually be possible to write a script that when run by the user goes through this log and makes the relevant changes to the code (though that would probably be down to the community to create once the "legacy" engine had the deprecation-identification functionality).
2. This is completely different to having beta versions before delivering a full version. IMO it would be several years (if not decades) before you could remove the "legacy" script engine - but clearly any new functionality would have no need for any backwards-compatibility, and so the "legacy" engine would effectively be stabilised code, with all new functionality being delivered by the "clean" engine - which I assume would be easier to deliver because that part of the code would be much cleaner.
Of course, this is only theory - only Khaled can say whether the existing code base is amenable to supporting both "legacy" and "clean" script engines.
