> "list or tuple" (of such strings.)  Can we say 'sequence' (or even set or
> iterable) or is the requirement specifically tuple or list?

No. The call() method accepted only tuples, and since issue21525 it now 
supports lists.

> Does tk call the traceback function with any args it supplies(other than
> those passed in)? (In other words, is the callback affected by the #22214
> proposal?)

Tcl calls the traceback function with stringified arguments. No, this is not 
affected by the #22214 proposal. And only types which are supported by Tkinter 
(int, bool, float, str, bytes, tuple, list, Tcl_Obj) are allowed. But this 
behavior can be changed in future versions of Tcl..

> "Should be same as were specified in trace_add()." Is a subset not allowed
> to remove a subset of the registrations currently allowed?  Does trying to
> delete other modes raise TclError?  If both are so, I would say something
> like "Must be a subset of current trace modes.".

Unfortunately both are no. If you pass wrong mode, trace_remove() will 
silently finished, but next attempt to call a callback will raise TclError 
(because a command is already deleted). Fixed in next patch and should be 
backported.

> That aside, remembering and passing the
> arguments back seems like a bizarre requirement that makes not sense. What
> happens if one does not, or gets it wrong?

Same bad things as when pass wrong mode.

> It the args are really required
> exactly, then is seems that trace_add should return (cbname,) + args to be
> passed back to trace_remove as cbname_args.

Looks good.

> Alternatively, could *args (and mode) be retrieved from trace_info?

You can retrieve mode, cbname and (stringified) args from trace_info. Currently 
following code removes all callbacks from variable:

for mode, cbname_args in v.trace_info():
    v.trace_remove(mode, *cbname_args)

With next patch '*' is not needed.

Thank you for the review. Updated patch addresses all your comments.