cmdEpoch

proc ::cb {cmd args} {
    # onEnter:
    # cmdPtr->cmdEpoch = 1 (because Tcl_DeleteTokenFromCommand bumped it *before* executing traces (deleteProc)
    # resPtr->cmdEpoch = 0

    # namespace origin will call Tcl_GetCommandFromObj (so checking Tcl_Obj cmd's cmdtype intrep)
    namespace origin $cmd
    # cmdPtr->cmdEpoch == resPtr->cmdEpoch evaluates to false, intrep is updated using the old cmd under deletion (!), then:
    # cmdPtr->cmdEpoch = 1
    # resPtr->cmdEpoch = 1 (because cmd under deletion is used)
    # Sooo: from that time on, unless there is a second cmdEpoch++
    # (2!=1) once traces (deleteProc) have been run, the Tcl_Obj
    # behind cmd will keep returning the wrongly? re-cached old cmd.
}

set cmd ::e

set script {
    proc $cmd args {;}
    $cmd
    trace add command $cmd delete [list ::cb $cmd]
    rename $cmd ""; # trigger Tcl_DeleteTokenFromCommand + traces; rename (if I get it correctly) will also cmdEpoch++ a second time; so Tcl is fine, but we were not
}

# eval script block so that cmd becomes cmdType early.
eval $script

##
## What we see (for our deleteProc, not traces) when creating a
## same-named cmd (::e) using $cmd, the Tcl_Objs cached cmdPtr points
## to the old cmd (which is a zombie once Tcl_DeleteCommandFromToken
## has completed.) So far, our deleteProc for the old cmd (::e) has
## not cmdEpoch++ on its own. We do so now and the problem goes away.
##