Lack of naming convention leads to name collisions and unexpected results.

I have just ran into a name collision from unpublish internal functions.

Your debugging application does not display all of the function names
that exist in a debug session. So I have no way of knowing which functions
names already exist in your software. Hence the collision when I chose
a name for a function as "constructor". My impression was that this was
a "stripped down version" of javascript. It had no reference to "this". I assumed
it did not implement normal associated javascript functions. Wrong!!

I had no way of knowing that such a function already existed. And in addition I did not know
that when I referenced it and tried to define my version that you would not
allow the overlaying of that function. For in all other function names it does allow such
replacement.

This problem complicated by Your use a "colloquial" vocabulary for attributes in your
widgets. "radius", "height", etc.. And when I define a property unique for my
widgets, you mix my property objects in the same list with all of your other
attribute names. There is no clear definition to which system the name is
owned. Is that a system name or a client software name?

The problem with this situation is one of "ownership". I have seen at least 3
major ($100K) situations in my 40+ years of IT development. In one of those cases, a 6 Billion
dollar company had to spend 10+ years to convert to a new release of one
of their major back office applications, due to name changes Because the vendor
told the client that they could use whatever names they wanted. When the vendor release
changes all of their system field names the IT department had to rewrite all of their
software to comply with the new naming convention to avoid this name collision
problem. It also happened at IBM, when system programmers modified OS system code so solve a needed function. Both of these problems were about ownership. Sharing names is not
a good idea (especially function names). A major design rule that appears to hold true
even today: Never use one thing for two purposes! (That is the same as saying one thing
can not be owned by two independent groups. The purposes of the groups will eventually separate and the master may become the slave). The case of the banks wanting to use
the Social Security Number as a unique person identifier comes to mind. If that had occurred
the banks would dictate how the government could make changes.

I hope you learn from history. If not continue to go on repeating those mistakes

I have tried to separate my "user" develop names from your free wheeling nomenclature.
All of my attribute names start with "_". The nice thing about this is that they all
appear at the top of the properties name list.

Rather than tell all of your clients to try to avoid using your names when they don't
know, it would be wiser to choose a simple naming convention that insures they
don't choose a name that clashes with one of your names. IT has been
doing that for decades.

And maybe if you choose a naming convention then you could separate the properties
list into two groups: one for system attributes and another for user defined properties.

Until you face reality that two groups can not own the same attribute name you
will be facing that problem. (As the bible says: No man can serve to masters).
Accidental collision with continue to place restriction on your system software
development, and on the software developed by your clients. It is best to keep
thow two environments separate.

Do as you wish. Mark this as a suggestion and file it in the circular basket.
Give your excuse that this is too big to tackle or not that important.
Stick you head in the sand, and claim it will not happen to Qt. Murphy's law
has not been repealed. And it will bite you at the worst time. And Murphy was
an optimist.