FYI @chunhtai since you recently also run into trouble with the upside down processing order in paint.

Figured out why this was breaking a test in Google3. A widget there is making brittle assumptions about the order in which nodes are processed during paint. The Render tree looks basically like this:

Overlay
  OverlayEntryA
     UninterestingRenderObject
        RenderObjectA
  OverlayEntryB
    RenderObjectB

RenderObjectA and RenderObjectB share some data via a shared object. When RenderObjectA paints it sets some data on that sharedObject, that RenderObjectB is supposed to use during its paint. This is assuming that A paints before B (if B paints first it will use outdated data as A didn't have a chance to update the sharedObject yet). Prior to this PR, we would paint the deepest RenderObject first and since A is deeper in the tree it was guaranteed to paint first. This PR is switching this order around and now B is painting first missing the updated data that A is producing during its paint.

Seems a little brittle to rely on paint order like that. It only works because A happens to be deeper in the tree.

That is definitely an invalid assumption. It's perfectly acceptable for siblings to be painted in any arbitrary order.

Actually, what I describe above is not some custom internal widget. Turns out, it's our Material Slider widget that has this problematic reliance on node processing order during paint. Filed #98770 for that with more details. We should also add a test for the slider to the framework that would have caught the breakage this caused in google3 earlier on this PR.