Oops, I did not mean to be harsh and apologize for coming across that way.
Tcl8 introduced the Tcl_Obj and a completely new api to deal with them. The old string-based interfaces were kept in place, because we value back compat a lot. They are flagged as deprecated in the manual pages and should only be used by legacy Tcl7 code, or when performance is known not to be an issue.
As to printing the list to the console: that should compute a string representation of the list object without discarding the representation as a list.
:) If you are using Tcl7 (Tcl8 is 10+ years old) or the OLD string interfaces on Tcl8, things go through the string rep and will be dog slow - your fault. Tcl's lists, for instance, are maintained internally as C arrays of pointers to the element objects. The roundtrip through the string rep can happen, but only if YOU treat the list as a string (more generally, as a non-list).
As to "deep changes to an old language": Tcl is actively maintained and still evolving. Tcl8.5 introduced anonymous functions among many other changes; Tcl8.6 (in beta) has a completely new engine (somewhat similar to py's stackless), coroutines and tailcalls, a builtin OO system, and many other enhancements.
Speaking with some knowledge of the inner workings of Tcl, I can assert that your description is not correct in recent Tcl: you must be doing something more to that object, or misinterpreting what is happening. I suggest creating a bug ticket at Tcl's SF site with a description of the problem and sample code.
Tcl8 introduced the Tcl_Obj and a completely new api to deal with them. The old string-based interfaces were kept in place, because we value back compat a lot. They are flagged as deprecated in the manual pages and should only be used by legacy Tcl7 code, or when performance is known not to be an issue.
As to printing the list to the console: that should compute a string representation of the list object without discarding the representation as a list.