The test case in bug #55634 also passes with the set_zliminclude patch.  I don't know why this should be happening either.  Unfortunately, this may require using the debugger and stepping through the three drawing passes in gl-render.cc to see when each object is being drawn.

Following up on my own comment #8, attached is a simple patch against the current development tip that allows the test case tst_reparent.m to pass.  All it does is restore the "set_zliminclude" call.

(file #53724, file #53725)

Thanks for tracking this down.
I was half expecting that this might be caused by some changes when `light` was added. IIRC, I had to touch the order in which objects are drawn to get the light source early enough when rendering.

I don't understand immediately how the changeset that Rik found affects the order in which objects are drawn though.
IIUC, that drawing is done in `opengl_renderer::draw_axes_children`:
https://hg.savannah.gnu.org/hgweb/octave/file/6646f2b5a3d1/libinterp/corefcn/gl-render.cc#l2210

Lines (including those in hggroups) should be drawn in "group #3":

   // 3rd pass: draw remaining objects

    m_glfcns.glDisable (GL_DEPTH_TEST);

    for (it = obj_list.begin (); it != obj_list.end (); it++)
      {
        graphics_object go = (*it);

        set_clipping (go.get_properties ().is_clipping ());
        draw (go);
      }

    set_clipping (false);

`obj_list` is populated here:
https://hg.savannah.gnu.org/hgweb/octave/file/6646f2b5a3d1/libinterp/corefcn/gl-render.cc#l2163

  void
  opengl_renderer::draw_all_lights (const base_properties& props,
                                    std::list<graphics_object>& obj_list)
  {
#if defined (HAVE_OPENGL)
    gh_manager& gh_mgr = __get_gh_manager__ ();

    Matrix children = props.get_all_children ();

    for (octave_idx_type i = children.numel () - 1; i >= 0; i--)
      {
        graphics_object go = gh_mgr.get_object (children(i));

        base_properties p = go.get_properties ();

        if (p.is_visible ()
            || (m_selecting && p.pickableparts_is ("all")))
          {
            if (go.isa ("light") && ! m_selecting)
              {
                if (m_current_light-GL_LIGHT0 < m_max_lights)
                  {
                    set_clipping (p.is_clipping ());
                    draw (go);
                    m_current_light++;
                  }
              }
            else if (go.isa ("hggroup")
                     && ! (m_selecting && p.pickableparts_is ("none")))
              draw_all_lights (go.get_properties (), obj_list);
            else if (! (m_selecting && p.pickableparts_is ("none")))
              obj_list.push_back (go);
          }
      }
#else

    octave_unused_parameter (props);
    octave_unused_parameter (obj_list);

    // This shouldn't happen because construction of opengl_renderer
    // objects is supposed to be impossible if OpenGL is not available.

    panic_impossible ();

#endif
  }

I'm not sure how any of this can be affected by the changeset that Rik found...

@Rik: I have looked at this issue a bit and haven't been able to identify its root cause (lines are drawn in the same order in gl-render.cc but sorted differently back to front depending on the number of lines, very strange). AFAICS, running the same offending example using patch objects rather than lines doesn't trigger the bug:

clf; hold on
h1 = hggroup ();
h2 = patch ([0 1 0.5], [0 0 1], "r");
h3 = patch ([0 1 0.5], [1 1 0], "b", "parent", h1);

and the blue patch is drawn below the red one, as expected...

So in the end, bisecting seems difficult (we'll have to inspect visually each resulting figure) but necessary.

Confirmed with Pantxo's example.

The problem is not the addition of the legend, which I could verify doesn't touch the axes children stack.
The red dot should be draw below the blue line right from the beginning since it is a children of the hggroup which is supposed to be drawn first. The bug is that until another child is added to the axes (what legend silently does), the order in which graphics objects are drawn may be wrong. Here is a script to demonstrate the issue:

clf;
hold on;
h1 = hggroup ();
h2 = plot (1:3);
plot (2, 2,"or", "parent", h1, "markerfacecolor", "r", "markersize", 50)
h3 = plot (3:-1:1, "-g");

Before drawing h3, the red dot is above, while after it is below other objects, as it should.

If you agree, I'll change the title to something like "Reparented graphics objects may be drawn in wrong order"