For buttons only that's ok but other widgets may need a press-release scheme and then you don't want to have inconsistent behaviour. Notice that pretty much all modern OS adopt this push-release way, which also plays better with inputs that aren't very precise (e.g. touch screen). It also allows to integrate other features such as drag and drop. Again there's no single answer it depends what you do, but 2 step is more in line with standard OSes.

Hmm.. Yes and no. If the user needs to read and write data from a widget in a rmgui context it usually means you'll have a copy of the data. There might be occasional cases were you need to store data, but compare that to rmgui where you always have to store data (you always need to store a handle to widgets).

That's the part that is less obvious to get right with an imgui implementation, and personally I haven't tackled layout very much yet (and hope to do so eventually). For the sort of tools I made, layout was rarely an issue. In practice, simple stacking horizontally or vertically, grid, or filling remaining space is generally enough. Creating resizeable spaces (like I'm doing with columns) isn't a problem. What's hard to get right is if you want to measure the size of items and feed that back in the layout in an submission-order independent way. It probably has to be done in two passes. Unity solves that by running the gui code multiple times (e.g. maybe in the first pass it only does size measurement, then layout, etc. just a guess). How I think I'll solve more intricate layout is that I'll have layout primitive store state and the layout would only be applied on the second frame (effectively there would be a frame of lag, perhaps for a new window it means the window isn't showing during the first frame. During resizing interaction the frame of lag shouldn't be noticeable). But this is a rather open topic that I suppose people are trying to address in different ways.

In Agui, I made a mouseClick event, which requires the press and release to be on the same Widget. If it is a left mouseClick on a button I give an actionPerformed event.

And I have too much code invested in my gui hahah. But this is really cool once you understand its potential. I'm surprised I had never heard of it before.

I dislike passing the properties of the widgets as parameters in your RenderWidget functions,
but that's easy to move into the gui context.
But on the whole I think this is a very elegant API.

I'm not converted to the immediate-mode paradigm,
but this has inspired me to allow immediate-mode processing of events in my gui library.
If your needs are simple (which is probably the case often enough) it really is very convenient to just handle all your events in one function vs. sub-classing widgets and adding listener routines.

I'm a firm believer in "creating options" for the programmer and not dictating methodology.

Thanks.