As far as I can remember, this being 3.5 years (and several projects) ago, I had a lot of problems putting things in lists, because some list functions seemed to be cavalier about turning things into strings, and I'd end up with my carefully-constructed list of Tcl objects turning into a list of strings that were all "" :(
The obvious thing to do is just turn an object into a parseable string. So if you have a Texture object, which is a struct Texture at address 0x12345678, you might let this become a string, "(Texture * )0x12345678" (or similar). And then if you're expecting a Texture object you can check for not just a TclObj struct of the appropriate type, but also a string of the right format. I'm sure I found this unworkable, though, my recollection being that Tcl would call the free callback on the original object after turning it into a string, and so you'd quite possibly end up with a string representation of a dead object... but now that I say that out loud, it sounds super insane.
So maybe I'm recalling rightly. And then Tcl is still insane, and I stand by everything I said. It happens.
Or maybe I'm wrong... and that's good! Because I otherwise really did prefer it to Lua. I know exactly why Lua's C API is the way it is, but that doesn't make it any less horrid. And Tcl's shell-style syntax is way better for interactive use.
The usual problem is to do with managing list construction, and the usual answer is the [list] command, which Does The Right Thing for sane code. We also made sure that such lists go through the script evaluation engine cleanly (except for the first word, which will be forced to be interpreted as a command name, obviously). I think we (well, mostly me in this case) sorted this out properly in 8.5.
Still, we don't recommend tying objects with important lifetimes to values; Tcl really assumes that it can clone and release them as it sees fit (and effectively that it can interconvert through the serialization without problems). It's a pretty different design decision to what most programming languages go with, and has a lot of consequences, some really good and some quite irksome at times.
There's quite a few extension packages that do the sort of thing you're talking about without trouble. In particular, the packages for handling talking to DOM trees, DCOM interfaces, and JVMs all take this approach without becoming disaster zones. Another approach is to put the magical value in a variable and refer to that variable by name (which is a bit more easily done when it is an array element). I'm sure something could be worked out.
The obvious thing to do is just turn an object into a parseable string. So if you have a Texture object, which is a struct Texture at address 0x12345678, you might let this become a string, "(Texture * )0x12345678" (or similar). And then if you're expecting a Texture object you can check for not just a TclObj struct of the appropriate type, but also a string of the right format. I'm sure I found this unworkable, though, my recollection being that Tcl would call the free callback on the original object after turning it into a string, and so you'd quite possibly end up with a string representation of a dead object... but now that I say that out loud, it sounds super insane.
So maybe I'm recalling rightly. And then Tcl is still insane, and I stand by everything I said. It happens.
Or maybe I'm wrong... and that's good! Because I otherwise really did prefer it to Lua. I know exactly why Lua's C API is the way it is, but that doesn't make it any less horrid. And Tcl's shell-style syntax is way better for interactive use.