There are a very few truly global entities there, most notably the current working directory and the environment variables. They're global because the underlying concept leaks through into C code you link in and subprocesses you launch, and changing that would be really quite nasty. The Tcl interfaces to those things are internally protected against multithreaded access, of course, but you can still get yourself into a mess that way.
The bit I really like about Tcl is how easy it makes asynchronous I/O across all its supported platforms. This doesn't sound significant to Linux users, but on Windows that's a very very big deal...
Long term, the Cisco router support became the non-recursive execution engine (of Tcl 8.6) which stopped things from blowing up on the tiny stack sizes that Cisco equipment is configured with.
There's no macros because there's uplevel (and upvar) instead. It's a different way to do homoiconicity. And the variable binding rules are quite different, which makes for quite a different language in practice.
The current main project for Tk, targeting the 9.2 release next year, is porting to work on Wayland. (But not dropping support for X11, Windows or macOS.) Apparently, the widget demo is now working (i.e., you could probably build some applications on it) but advanced features like accessibility support are still in progress.
You need tools adequate to the task, but the task isn't necessarily what other people think it is. In this case, I'd bet the tasks are to learn what's going on inside a database and become better at programming in Python, not to write a high-performance production-ready database implementation.
Almost all quoting for non-trivial cases comes down to the [list] command. It does the Right Thing, especially in the critical cases where you're generating a command to call later. Pretty much everything else is either much simpler to the point of needing no thought at all, or complex enough that you're best off writing a command to do it properly (e.g., because you're generating JSON or CSV or some other language like that) as you'll want to test it thoroughly too.
It's hard to be much more specific than that without talking detailed examples.
The main issue with supporting those IDEs is that the Language Server Protocol is vast and really quite complicated. More than a weekend's work to go to doing the interesting bits so life gets in the way...
The IDE tools for Tcl have tended to be commercial and to not see much general adoption. Never understood why.
Python has nothing at all like safe interpreters (I've looked). You just can't prevent things from leaking, it isn't designed for it at all. You can do a half-hearted approach by specifying the globals dictionary to eval(), but you can't really count on safety because the builtins do the leaking and you can't really stop anyone from finding a way to get back to that; the language is just too deeply interlinked for a proper security boundary to be erected anywhere inside it.
Well, there are classes and objects in there now. They're designed for modelling pretty heavyweight entities like widgets instead of lightweight things like linked lists.
It was a fun OO system to write. It's much more dynamic than it appears to be at first glance; it's first glance looks much like many other languages object systems with a few slight oddities (no new operator, but rather classes have a new method).
Technically, all values are considered subtypes of strings, but the notion of types is quite different to those of many other languages. In particular, Tcl's types do not describe the memory storage model of their values. (They're implemented with 64-bit words and buffers and arrays and so on, but that's not what the value model describes.)
It works well as long as your goal isn't to totally eliminate boxing of values.
The bit I really like about Tcl is how easy it makes asynchronous I/O across all its supported platforms. This doesn't sound significant to Linux users, but on Windows that's a very very big deal...