Re: backward compatibility... I'd say Tcl is remarkably stable. A core tenet is "everything is a string" (EIAS), and logically, this has been honoured. Originally (before Tcl 8, or 8.4(?)) internal components of Tcl were literally strings. As in C "char " strings. It is (and has been) byte-coded for a long time now, and uses Tcl_Obj internals, with a string representation, and a high-performance "native" representation as well. It does still logically behave as if EIAS, though.
That cited doc you mention doesn't actually seem to have a bearing in reality for some of its assertions, to my eyes. It would perhaps have "gotchas" for authors/users of scripts, but doesn't invalidate the EIAS core tenet. Additionally, that document was last edited 20 years ago. It's ancient, as is Tcl < 8.0.
You are lumping them together, as you mention, but they are very different precisely on this regard: Scheme has a lot of very different implementations but code portability is an issue, while Lisp (Common Lisp) has a dozen implementations but code written in CL will generally compile and run straight away in any of them, due to language standarization.
Another lisp-like language to consider is Clojure, in its JVM implementation.
It isn't difficult to jump from Scheme to Lisp and viceversa; they are similar in many aspects.
If you want a quick comparison between Common Lisp and Scheme it would go like this: Common Lisp is a standarized, extremely powerful and flexible programming language; while Scheme is a do-it-yourself kit for creating your own extremely powerful and flexible programming language.
I wonder whether it's even true of Tcl. Tcl has had moving target semantics over its lifetime so in fact there are multiple implementations of Tcl. How well does the current Tcl emulate previous versions, so that code can run unmodified, and how far back does that go?
Here is a Tcl page that lists some semantic changes from 7 to 8:
ftp://ftp.tcl.tk/pub/tcl/doc/compiler.html
Even though many of the changes are for the better, yikes!