This is the extract of a side discussion from there
about how widget names should be renamed / renumbered when a widget is duplicated that already has a handle name. Further discussion on this topic should be done in this thread, please. 
Erik (as Mod)
This started with the following question:
As far as i can remember, these kind of names appear, when you have a widget with a handle name and then duplicate it multiple times.
EDIT: Yeah, just tried it… it happens on duplicating.
Would be cooler if the counter was a bit more “intelligent” and would recognize a number (or an underline plus number) at the end of the name and the only increment this…
Exactly, I recognize this naming very well 
Something already exists in GP for this as the Plugins with identical names are renumbered this way…
Ah - I never do that - as soon as I duplicate, I rename the widget - that’s why I didn’t remember.
I almost feel we should force a dialog to popup when duplicating to encourage renaming but of course that would slow down workflow.
Hm… why not analyse the name for an existing end-number and then just use this as a counter.
Appears to be not more complicated than the existing approach or even a dialog?
Suppose you have the following widgets among others
Volume
Volume1
Volume2
Volume3
Volume6 (because we deleted a few)
Now you decide to duplicate Volume2
What should be the default new name?
Good question… either it should search for gaps, so it would continue with Volume4, 5, then 7
…which feels a bit strange.
(EDIT: But that’s exactly how the auto-numbering works with plugin blocks! Thanks @David-san )
or
It should look for the highest number and continue from there, so the next ones would be 7,8,9…
In my opinion either one of the two would be “better” than Volume1_1_1_1_1_1 or such.
If one doesn’t delete something in between, there would be a clean chain of numbers.
And if one does delete soemthing in between, the widgets had to be renamed anyway - the same like it is now, only with shorter names, respectively much less characters to change!
Yeah, it’s that “look for” that is the catch.
If you’ve got hundreds of widgets (which many have), looking for a match (to make sure there isn’t one) can take time.
I’m sure that there can be some clever optimizations if we stop to think about it for some time but what other stuff that everybody wants should we stop thinking about to focus on this? Is it really a major thing? Is every customer madly duplicating widgets?
I actually use the GP widget auto-renaming all the time. In the manner I copy/paste widgets, it works well.
I often create widgets in banks of 8 (because control surfaces often have banks of 8). In my extensions I look for them to be names something like “fader_0”, “fader_1”, “fader_2”, etc.
If I name the first one “fader” and then copy/paste 7 times I end up with all of them being named correctly and then just need to add the “_0” part to the first one.
Not at all, I think.
I dare to say that <99% of all the rackspaces have much less than 100 widgets (not to speak of hundreds - my most occupied panels may have around 50), also we’ve seen some rackspace here where there was a huge number of plugin blocks, and there (in the wiring view) this duplicate numbering is established and works. Also building a rackspace panel is not that time critical.
No, it’s not a major thing and nobody expects you to stop more important things you’re on - nobody said something like this - but i think it should be something to be taken in account though, if there is some time left.
Regarding the “mad duplicating”… no, i don’t think that the majority of users will have a real use of it, but those few of us who do and who often give the community those eye-candy-panels (which people actually seem to like), those would greatly apreciate it because they are the ones who have to struggle with this auto-naming convention.
But as we all agree, this thing is not a priority issue… it just would be nice if it could be improved at some time.
BTW: Should i extract the discussion around the auto-numbering into a separate thread, or can this stay here?
As far as I’m concerned, I would be happy when the handle was not copied, just left blank. But really not a major thing to me
That’s a very good point
Good idea.
And yes, I answered perhaps a bit quickly what I was thinking about the auto renaming, but supporting power users like @schamass in their achievements, by improving their workflow, for the benefit of all, probably contributes in some way to “strengthening” GP. How many times have I read here or there that GPScript is for some happy few. Maybe, but if those who program these GPScript are rare, there are many more who they could help and probably even more who use Scriptlets happily and without necessarily saying it.
So, finally +1 for @schamass
No question — it really just becomes a question of how to fit it in with other stuff. Unfortunately something that gets forgotten often with features that seem like they should be trivial is that they can come back and bite you and significant testing of many scenarios becomes critical.
I don’t remember what it was anymore, but some years ago, we added some cute feature to widgets that seemed really awesome at the time, worked great in our tests until someone who had over 200 widgets in their rackspace got severely impacted because whatever we did really slowed things down if there were many widgets.
So for example, a naive solution would be to keep a global widget “duplication” counter and every time you duplicate a widget we would just grab the name, remove any number on it (if there is one, and how do we know whether we put it there or the user did!!!) and append a new number, incrementing the counter.
But what happens when you load the gig again? We can’t start that counter from 0, we’d have to start from the last value (why not? see below). But that means that over time, copying/duplicating widgets will end up with large numbers on them anyway…not what we want.
Why couldn’t we start from zero? Well, because then whenever you duplicate a widget we would have to iterate through every single widget to find a “missing” number that we could reuse. Now imagine you have 100 widgets and you decide to duplicate 6 of them – now you’ll have to check 100 widgets 6 times.
I guess the point I want to make is that just because a suggestion/feature seems like it would be trivial, (leading customers to wonder why that suggestion doesn’t quickly get implemented or is deferred, etc), under the covers it can be incredibly complicated to get it right.
I agree, that’s objectively something you have to take into account that we can’t. And you are perfectly in your Dev role in slowing us down. That’s why @schamass concluded wisely by:
Maybe like other options you could enable/disable in GP settings, with the default being the disabled state. The only ones who would turn it on would be those that need the feature? lower risk and pressure to make or tweak it if it needed to be modified?
At some point maybe GP could have a “power user” setting where you have these types of features for those that push the program and scripting to the limit, with possible beta features for those that you know will try them out and work with you to accurately test and report on how they work? You could then see what the demand is and move to prime time if popular enough.