Oh I see, sorry; when I first clicked I thought it was just an update to the examples folder of gtkmm.
The key to avoid this is to never use the parenting/unparenting of widget from C++ code. So as long as you inherit from Box, or a similar container, you're good. Then the unparenting is handled in C-land.
It seems you're right; unparent() is suggested to be called from dispose, and dispose is not exposed in glibmm. sigc++'s add_destroy_notify_callback is definitely too late. Widget's destroy signal has existed prior to gtk4 but I see the gtkmm bindings are not wrapping it; nor is the signal explicitly ignored, so I'm not sure why.
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.
