As mentioned (forcefully) by Larry, backward compatibility is a reasonable goal but is preventing progress in a number of areas.

The New Tcl language core (a.k.a Tcl 9) is the time to break this compatibility where appropriate - not gratuitously but to remove the accretion of nearly two decades years of development and allow those with new ideas (e.g. Joe, Miguel and others) to take the language forward.

There are two possible paths to a cruft-free, legacy-free codebase - one way is to clone Tcl 8.5 and start tossing out the cruft. The other is to start afresh, and copy/paste/cleanup bits from the old codebase as needed. Joe offered an interesting suggestion - do both in parallel and whoever gets there first wins :) But perhaps a combination of these two approaches will work well - decide at a high level which features are retained, and then use whichever approach is more appropriate when implementing. The key is to free up

the Tcl maintainers to improve the codebase (and have fun doing so) without having to worry about backward compatibility - this is a “once in a generation” opportunity.

It is anticipated that most of the incompatible changes would occur at the C API level, and that scripts would be mostly compatible. But Joe has raised the point that features should be considered for inclusion, rather than taking all existing features and say “which ones should we omit” (Joe, please expand).

Jeff / Joe / Miguel / Donal / whomever please expand on incompatible changes you are hanging out to make

• package system mods for speed?
• return code stuff
• bytecode reform
• other stuff?