Interesting, it had not occurred to me that exposing
the "attributes" of the underlying label was not enough.

i.e. you can still embed your GtkLabel and set markup on
the label, but then you dont get to leverage the image-position
property and image property (and you also end up with customized
hierarchies that dont always match the guesswork done by themes).

I think the best solution all around would be to expose
the GtkButton's label as a property just like the image widget, 
allowing the button to control the alignment/box and handle 
image-position properly, and also allowing full customization of the label.

Any updates on this?

Nothing changed here, and since by now the GtkButton provides
the "label-widget" property I dont think it's reasonable to add
more api where it's unneeded.

I.e., you can just as well setup a GtkLabel with your attributes
and make it the "label widget" of the button (while adding
custom contents to the button directly is error prone, because
the custom contents would not comply to desktop "show-images"
setting... as well as it's not obvious to get the GtkButton
hierarchy right, i.e. button { alignment { hbox { image, label } } }).

My opinion, no reason to bloat the button api with this.

GtkEntry would be an interesting case to implement <attributes> on though...

Ugh, it seems I was wrong, GtkButton doesnt expose a 'label-widget'
property, only the 'image' property is currently exposed.

Let's rephrase then, I think it would cost less code and cover
more ground to just add the 'label-widget' property to GtkButton
rather than to replicate the attributes parsing there.

I don't like adding random extra properties for children, tbh.
It only adds confusion.

Perhaps a "label" <internal-child> supported at the GtkButton level would be
most appropriate to cover this sort of thing.

The odd part of that is; the label widget is not always valid; its only
valid if the GtkButton is actually setup to create the label.

Of course that could be documented, and Glade could optionally expose
the internal label for configuration *if* it's setup to create a label.

I think it is better to explicitly create a label when one is needed.