I think Tcl is incredibly elegant. It's got a set of very simple syntax rules that compose together to govern everything. You can use Tcl to create your own keywords that are used exactly like the built-in ones and your caller won't ever tell the difference (well, unless they inspect an error backtrace). For example, a try/catch syntax was proposed as TIP 89¹. And many many years ago, as part of the MacPorts project, I implemented the entirety of TIP 89 in pure Tcl. The TIP was proposing actual Tcl keywords, but I implemented exactly the proposed syntax and semantics without a single keyword. I have no idea if that code exists in any form anymore (I haven't been involved with the project in something like a decade), but I'm pretty sure the only observable difference between that and TIP 89 is error backtraces² that cross a frame involving try/catch.

Also, virtually every type³ in Tcl can be expressed as a string, and so you can model the entire language mentally as if every value was in fact a string. If you wanted to write your own Tcl interpreter it would be pretty easy to actually implement it this way, though obviously performance would suffer quite a lot.

¹Later superseded by TIP 329 in response to the error options dictionary in Tcl 8.5.

²And FWIW I believe there's no actual spec for what error backtraces look like anyway, I think it's implementation-defined, though don't quote me on that.

³The only type I know of offhand that can't be expressed this way is an array (which is distinct from a list, that is a fundamental building block of Tcl and can absolutely be expressed as a string)