[bdowling]

A naive implementation would have the problem you describe. However, a smarter library implementation avoids this (e.g., by generating an id for the button, saving the id on mouse-down, and checking the id on mouse-up). The user of such a library won't have to worry about it.

[amluto]

And how, exactly, is the id created? Some hash of the button’s text and coordinates?

I would call that a dirty hack, no to mention being implicitly stateful.

[HelloNurse]

But a stateful GUI is not a sin: the program as a whole has state, application code needs to process GUI inputs to update application-level state (e.g. currently set game options) while tracking mechanical details like whether a button is "half clicked" is suitable for automation at the GUI library level.

Regarding IDs, they can (and must) be provided by client code, as client code is responsible for managing widget identity (i.e. whether the button that might have a mouse up event this frame is "the same" that received a mouse down event some frames ago). In C or C++, string names could usually be autogenerated with trivial macros relying on __LINE__ and __FILE__.