First thoughts on the proposal.  I overall like it.  The 'virtue' of the digit strings names is that they match tk behavior (I presume) and are consistently opaque ;-)  *Someone* will object to change.

Is your proposal to have (_)tkinter add a name= option when not provided by the user?  The main problem I see is breaking code that assumes digits if no name= options are given.  Is this currently guaranteed?

1. Canvas item ids are, in Python, ints (though I presume int strings in tcl) starting with 1.  They number consecutively within canvas, regardless of 'type'.  I wonder if tk uses them a indexes into an array of items for a particular canvas.  I think I prefer sequential within class.

Something else, I believe, generates alphanumeric names similar to what you propose.


2. Follow.

3. '#' seems a bit heavy, as it tends to overwhelm '.' as the separator.  I think leave it out or use '-'.  ".frame1.button2" or ".frame-1.button-2".  I prefer without.  These could be names I would give if I were to add name= options all over the place, except that it is too easy to reuse a number.  

Conflicts: tk does not prevent duplicate names by users.
...
>>> entry2
<tkinter.Entry object .e1>
>>> entry
<tkinter.Entry object .e1>
I am not sure of the consequence of this.

The doc could say, "If you want widget names of the form <class-name(lowercased)><sequence number> either consistently supply them yourself with name= options, or let tkinter supply them for you."