Adding a virtual method to an existing class breaks ABI. It won't be done.Beyond exposing the destroy signal, another approach might be adding a virtual dispose method if there is some known problem with sigc++ at this point in the object lifecycle.
Maybe Kjell knows there is a good reason to not expose signal destroy / dispose in gtkmm? If so you'd have to settle for subclassing a container, but otherwise I'd prefer all signals to be available.
No, I don't know why the destroy signal is not exposed in gtkmm. Probably no one thought it would be useful. Even confusing to most users? It's not explicitly ignored, probably because no one has been sure it's useless. And now it seems it is useful, even necessary, to some users.
I don't mind adding Gtk::Widget::signal_destroy() to gtkmm4. I'd prefer a merge request, If you, Baldvin, have write permission to gitlab you can even add it yourself. Adding a _WRAP_SIGNAL is trivial, but it needs a better description than the one that will be inherited from gtk.
Is this an issue mostly for people who write widgets intended for others to use in their applications? I suppose that people writing application programs wouldn't mind using boxes, grids and other container widgets.