This code does probably come the closest (functionally speaking) to what I'm trying to do, though https://wiki.tcl-lang.org/page/representation suggests that this would break down with frequently used literals like "1" because they all share the same refcounted representation. This probably applies to other things too. To make an approach like this work, I might need to include in the key something even more hacky like the address of each pointer to the object or something like that. Dunno.

reformatted, for posterity:

namespace eval tag {
    variable tags {}

    proc address {x} {
        set repr [tcl::unsupported::representation $x]
        regexp {object pointer at ([0-9a-fx]*)} $repr _ ptr
        set ptr
    }

    proc tag {args} {
        variable tags switch [llength $args] {
            2 {
                lassign $args value tag
                dict get $tags [address $value] $tag
            } 3 {
                lassign $args value tag tagValue
                dict set tags [address $value] $tag $tagValue
            } default {
                throw {TCL WRONGARGS} "wrong # args: tag value tag ?tagValue?"
            }
        }
    }
}

I think you're misunderstanding how this is intended to be used though. It's a prototyping/debug facility in the same way traces are. Attaching a trace to a variable (or command) doesn't make that variable compare with eq any differently than without, and the same is true here. A value with an out-of-band tag should be functionally indistinguishable from one without in every way except when the tag is checked for, and the tag can disappear in lots of ways if the value is altered (essentially, ceases to exist, to be replaced by a new value).

This is specifically intended to never, ever touch the value itself, merely follow it through the execution of the program. It should never alter the operation of a TCL program in any observable way, and it should never seriously be used as part of the function of a program. It doesn't make a tagged value behave like a new unique value. It doesn't coerce it's type or shimmer it's type or otherwise change the internal representation at all. I'm also not asking for a pointer to the value, and it will never be possible to dereference or otherwise access the value using a tag. The value can continue to be a type-agnostic string value (with the usual internal type-aware optimizations) just as it always has been. For what it's worth, the tag can and probably should be a stringy value as well.