The official 8.5.0 release of Tcl/Tk was released a couple of days ago, after several long years in development. I've updated my Busy Developer's Guide to reflect that version.
All in all, this release is a very good thing on many levels, and the people who put so many hours of work into it deserve thanks and congratulations. It's a significant release both due to the improvements in Tcl itself (which at a day-to-day level remove some real annoyances), but particularly at the Tk level. With the inclusion of the themed Tk widget set, it marks the first time that the core version includes pretty much everything needed to make a non-embarassing post-1990's graphical user interface. While it's probably unfortunate that there was so much distance to come from behind, that doesn't undermine the significant step that was taken. Again, this is a milestone.
Now that it's official of course is the time where all the armchair quarterbacks start taking a serious look at it, when it would have been more helpful if they took several serious looks at it during the extended alpha/beta periods. I'm ashamed to count myself in this group as well.
Tcl/Tk 8.5 definitely feels like a transitional release; it moves a lot of things forward, but it's not polished. With how long it took to get out, that's probably a good thing, or we'd never have seen it. The trick now is moving much faster towards the polished version (8.6 presumably); my understanding is that there is fairly great motivation in parts of the community to do this.
On the Tcl front, things are in really good shape. The one main thing that got cut because of not enough experience with it is the core object system. Getting that up to snuff and included in 8.6 is necessary of course. The other thing that will probably take some polishing is the new module/repository features, again because only now will people really start to bang on it.
Tk has further to go; again, this is not to diminish the great leaps forward in 8.5, both in the new widget set but also in improvements, optimizations and bug fixes (this is particularly noticeable on the Mac). As I said, everything is there now in the core needed to build a decent modern GUI, but it's still not easy or obvious. You still need to know what you're doing. The obvious polishing will occur in the new widget sets as more people now bang on it, and uncover bugs and omissions.
The bigger thing though is that the "transition" from classic-Tk to modern-Tk (new widget set) is only partially complete, and therefore inconsistent, and will be very confusing for the newcomer. The widget demo, while improved, is a mix of new and old (and some embarrassingly old). Again, no criticism intended for the core people, as it should be people like me who help bring those sorts of pieces up to date.
Being forced to make a choice (a tk::button or a ttk::button?) is still prevalent, and it's important we jump past that as soon as possible. There should be no choice needed... you use the new one. Oh yeah, and for the really advanced people, if you need to do something particularly funky, just ask and we'll let you know about this other uber-flexible 'classic' widget set that is available behind the scenes.
My fear, as with all things Tcl/Tk, is that there will be a vocal community of "no, it's important that people should know about both and choose, because choice is good" which will diminish the need to push forward to having the main official widget set which is Tk (currently Ttk!).
That of course brings up the other issue, to do with naming. Themed Tk (which started out as Tile) was originally an add-on, so when it was incorporated into the mainline, it was added as its own namespace "ttk", while classic Tk was placed in a "tk" namespace, as well as imported into the global namespace. Fine for now perhaps, but move forward into the future where we presumably want the new widget set to dominate for app developers.
Do you tell users of "Tcl/Tk" to not use the namesake "tk", but instead use "ttk"?. Why is it called "Tcl/Tk" then? That seems to be setting everyone up for confusion (choice is bad!). While there are some backwards compatibility issues to think about of course, how that transition is to work long term I'm not sure about. (Having said that, I'm sure it's been discussed, and I was either unaware or more likely forgot about it).
If the idea is long term the idea is to move to "Tcl/Ttk" instead, that could work. Given the shitty reputation of Tk, it also opens up the opportunity of rebranding it with a completely different name, completely unrelated to Tk. Imagine people using things from an entirely new "gui:" namespace (not that generic of course), so that everything that is in there is what we want to be in there and we want people to use, not because of backwards compatibility. The goal then becomes obvious, to move all the "highly recommended" standard official stuff into that namespace, with the behind-the-scenes remainder sitting in "tk:" and "ttk:". A lot of work to do that, but so much of it is also documentation and demos that don't require core-level rocket scientists.
In any case, I think the really hard work, the first 80%, has been done and done well. Now it's only the other 80% left. But with the hard parts done, there's going to be a lot more interest and energy in moving things forward. This is especially true among the Python, Ruby etc. folks who will now be looking to incorporate Ttk into their official GUI bindings. I think, if some of the historical inclinations within the user community can be overcome, things are actually in a really good position right now.
