The test code from comment #5 now works just fine. Marking as fixed and closing report.

In Matlab, the order of the creation of the two uipanels does not matter and I don't seen any difference between using "allchild(F)" and "allchild(gcbf)".

And what if the order of creation is reversed in old Matlab as well?
Does "allchild(F)" in the callback give the same list as "allchild(gcbf)"? Just want to make sure it's not some special view of the figure object that has different properties for the duration of the callback.
Assuming those are both fine, and the order we are doing things is backwards, the change looks like reversing the order of gh_manager::free(h) and parent.remove_child(h) in a few places in graphics.cc. Some other devs more familiar with the graphics system should weigh in on whether this is safe or worth doing.

Here is what an 'old' version of Matlab returns:
(the extra handles correspond to the toolbar and menus)

Thanks. I notice two things: the first one is that the error depends on the order in which the two uipanels are created. The following returns an error with Octave:
while this runs fine:
Matlab behaviour follows in the next comment.

By the way, there is a comment in the Octave sources dating from 2011 claiming an intentional order of operations here:
> NOTE: free the handle before removing it from its parent's
> children, such that the object's state is correct when the
> deletefcn callback is executed
This seems to imply that the decision was made intentionally to delete the child object, which calls its deletefcn callback function, before removing it from the parent's "children" list. So which way is correct?

Ok, reopening and retitling to reflect that specific error.
Can you show what the contents of allchild(F) is before and during the callback? Maybe Matlab is removing the uipanel from the children list before calling the deletefcn callback?

Thanks, Mike. Sorry, this bug report is confusing because I mentioned two separate issues and the title I chose relate to the second issue that is of lesser importance.
I agree that deleting a deleted handle is not a primary problem and can be left for later when/if graphics handles are implemented as objects.
There is still the issue that the following code returns an error:
while it runs OK even for Matlab versions that implement graphics handles as double.

I see.
So we are behaving correctly within the constraints of what we have support for currently in Octave.
I don't think there is much point to keeping this open just to remember this for when graphics handle objects are actually implemented.

Mike,
your examples throw the error "Invalid or deleted object."
This error is also thrown for the following example in current Matlab versions:
The reason why no error is thrown for the original example in comment #0 is probably that recent versions of Matlab return a graphics object instead of a double for handles.
See: http://de.mathworks.com/help/matlab/graphics_transition/graphicshandlesarenowobjectsnotdoubles.html
Octave did not (yet?) make this transition.

You get this:
In recent Matlab versions, handles are objects:
allowing for a second silent deletion as in original post. With older Matlab versions, relying on doubles to store handles, you get:
i.e. the same error message that you get with delete(42).
I might have added confusion to this thread though as the initial problem is somehow different as older Matlab versions (that behave like Octave regarding deletion of an already deleted handle) do not crash when the figure containing the uipanels is closed.
It seems that the code in graphics.cc (_go_delete_ and delete_graphics_objects) takes care of handles that might have been already deleted by a callback function but it must miss a case.

What about this in Matlab (in a fresh session with no handles)?
No errors or warnings, just silently do nothing?

Here is a simplified version of a situation I came across:
Closing the figure removes the right panel then crashes with this error message:
In particular, with Octave:
whereas in Matlab:
