But if you could attach your own OnClick method to the button, only one method can be called when the user click on the button, which would be a huge problem for many gui objects.
Put the calls to the other ones in that method. Treat it as a stub method.
And I am not against a "listener registry" or whatever one wants to call it, it's just that a dev shouldn't have to deal directly with it for the vast majority of typical UI coding. Have a convenient front-door for the vast majority of "customers", and a back-door for specialized fiddling. You could stuff a hundred additional on-click events for that button into the listener registry if you wanted. A default on-click method doesn't prevent that. (Hopefully there is a priority code to control order of handling.)
Also, one could put a general event handler on the button's container, and do the other handlers that way, using reflection or environment info to know what widget and what action triggered it.
There are many options without having to deal with lambda's. Would you like to present a specific use-case to explore further?
(I've been trying to invent/define a table-oriented GUI engine that is mostly language-neutral. Most events can be handled using tablized attributes instead of imperatively coded behavior. Everyone's just used to hand-coded behavior out of industry habit. It's poor tool/labor factoring to re-invent a GUI engine for every different programming language. A good language-neutral GUI engine could be attached to any language.)