> If there's some scenario that framework will not handle properly
> I'm genuinely interested in knowing what it is.  I need a demo.

Allow me to make that more precise.

If callers of Tcl_ObjSetVar2 follow the advice I spelled out before,
there will be no memory leak, and there will be no segfault due to
a double-free of the value.  I don't know of any counterexample,
and you have not given me one.  That's what I mean when I claim
that Tcl_ObjSetVar2() is bug-free when called properly. Note that
in most cases "called properly" means do nothing about the
refcount of value at all, which is very convenient.

Now it's becoming more clear to me that your objection is a bit
different. You not only seek to avoid memleaks and double-frees,
but also seek to avoid turning unshared values into shared values,
and you're looking for an improvement that can achieve that too.

I don't fully understand your TCL_OWN_OBJREF idea, and the
branch  fix-8-5-578155d5a19b348d seems to be out of date.
Is there a patch anywhere of the change you seek?

I think at a minimum, any change to Tcl_ObjSetVar2() has to
keep the following existing calling convention operating
successfully without leaks or crashes:

if (NULL = Tcl_ObjSetVar2(interp, arr, elem, Tcl_NewObj(), flags)) {
    /* Handle error */
}

Does your proposed patch preserve this 'fire and forget' mode of
operation?  Or does it impose the burden of needing to add the
TCL_OWN_OBJREF flag to flags in order to maintain that functionality?