I can't comment on virtual-table shenanigans, but I'll enthusiastically confirm that thought. Not only is an in-memory database powerful and useful for all the obvious reasons, but (I would argue) the Tcl interface to SQLite is perhaps the best relational database API in any language. (Even if it cheats a bit by being an embedded database, as with <https://sqlite.org/tclsqlite.html#function>.) It's easily as synergistic a combination as Tcl and Tk themseves, possibly more.
I don't (personally) like to think of the type system as "everything is an auto-mutating and cached tagged union + string" - from the perspective of someone writing in Tcl, everything absolutely is a string. It's cool that the implementation happens to store some strings as integers, or arrays, or hash tables, or whatever else as a performance hack, but unless you're actually working with Tcl_Objs at the C level, you generally don't need to care about that.
You are correct that, on Tcl level, everything _is_ (behaves like) a string.
But there have been too many discussions about how horrible this is for performance, that it is always worth mentioning the fact that internally this simplistic view is not true.
The definition of "standalone application" is a bit stronger - what's always been possible with "Tclkits" has been to embed the application code in an interpreter binary and distribute that, and the new core zipfs supports that as well.
A theming engine went in something like 15 years ago now; the default theme looks rather dated, but there are plenty of others. See https://wiki.tcl-lang.org/page/List+of+ttk+Themes (though the screenshots of core themes are from 8.5/8.6 - default in particular has changed a bit in Tk 9).
The "catch" is that the theming engine has its own new widgets, and so to be themed an application has to use the new API. Code from 1995 (or 2005) still produces GUIs from 1995.
Yeah, they added that a long time ago, but it's not at all the same as built-in support. My experience was trying out fragile third-party projects with little or no documentation. The whole point of using Tcl/Tk for writing a GUI was the convenience.
Things may have changed over time. I no longer pay attention. Maybe I'll give it another try.
The theming engine is absolutely "built-in", as are a handful of themes; in particular aqua and the winnative/xpnative/vistanative family (which integrate with the Mac/Windows windowing system such that the application will look "native" by default on those systems).
> which integrate with the Mac/Windows windowing system such that the application will look "native" by default on those systems
That's my point. You can make an app that looks okay on those OSes, but all of the built-in options for Linux look ridiculous, and then you're back to the third-party stuff.
I don't think clam looks "ridiculous", but I suppose we're in to subjective stuff now. :)
In principle this isn't really any different from GTK or Qt theming (where it's up to users to go forth and find themes they like, and set the default as desired), but in those cases you tend to get themes packaged up by distributions and GUI configuration support from desktop environments, and neither seems likely to happen for Tk.
If there's any better relational database API, in any language, than SQLite's Tcl interface, I've not seen it yet. (And the reasons SQLite's Tcl interface is so good would either be hard to replicate without Tcl, hard to replicate without SQLite, or both.)
From the (little) I've seen of that world, I'm not sure the EDA vendors understand Tcl very well either; I wouldn't want to work with scripts for Cadence's schematic capture tool, and that's not because of Tcl, it's because their scripting interface is a disaster. (Exposing C++ iterators at the script level, for example.)
