What is the benefit of using slot vs a list of child where the index is the slot? can it be a special version of multichildrenderobjectwidget where the element can be null?

It's a different mental model. For the MultiChildRenderObjectWidget, the children are more or less uniform and have the same semantic meaning (e.g. entries in a row). Whereas in a slotted render object, the children in different slots can have different shapes and different semantic meaning (e.g. a list tile has a slot for a trailing/leading icon and a title, etc.). In the MultiChildRenderObjectWidget case, children are interchangeable (the first item in a row can easily switch with the second one and vice versa). For a slotted object that often doesn't make sense (the leading icon of a ListTile doesn't make sense to be the title).

Of course, the slotted model can be mapped to the indexed model, but now you have the additional overhead of keeping a map between a semantic slot and its index.

And then there's the fact that the MultiChildRenderObjectWidget is especially engineered to not allow null-children. In the slotted world null is totally acceptable for a given slot. Of course, you could work around that, but it would make the mapping between slots and indexes even more complex.

Sounds good

The bottomRight child is constrained to the size of the topLeft child? Just making sure that's what you intended. Above on the first line of this method you comment that they are both unconstrained.

I think I'm nitpicking unimportant things, I know this is just an example :)

childConstraints is initialized to BoxConstraints(), which defaults to unconstraint constraints. So, bottomRight doesn't get to know anything about the size of topRight. It should therefore be unconstraint.

"constrains it" => "constrain it"

Well it's immediately clear how much unnecessary code this is saving 👍

"Implementor" => "Implementer"

I thought there was something about this in the style guide but I couldn't find it. Anyway, grepping through the rest of the framework code I see that it's always spelled with "er".

Why is the type parameter S instead of T?

S for Slots :)

Another "or" => "er".

Delete this empty line here.

values

It would be helpful to briefly explain why createRenderObject and updateRenderObject copy the widget's configuration to the render object, except for the widget's children.

I took a stab at writing an explanation. Does this make it clear?

Yes, it's clear enough now. A developer with a burning desire to know more can follow the path from here pretty easily :-)

Why are the types in this example private? There's no harm in it, but the code might be a little easier on the eyes if everything was public.

It might be worth noting that this property's implementation is boilerplate that matches the corresponding widget property. The only decision the developer actually has to make is choosing markNeedsLayout vs markNeedsPaint.

Added.

It's odd that we have to use _topLeft! instead of topLeft.

Assigned it to a local variable. Does that look cleaner?

Yes. I hadn't understood why _topLeft! was needed. I guess the way the code was, the compiler couldn't guarantee that _topLeft wouldn't be reset to null as a result of some side effect within the body of if (_topLeft != null) { ... }.

This is a little bit confusing since there's an offset parameter and you're referring to each child's (child.parentData! as BoxParentData).offset. It's obvious if you look at the _paintChild method - maybe just make paintChild() a local function.

void paintChild(RenderBox? child) {
  if (child != null) {
    final BoxParentData childParentData = child.parentData! as BoxParentData;
    context.paintChild(child, childParentData.offset + offset);
  }
}
paintChild(_topLeft);
paintChild(_bottomRight);

Is this override needed for the example? If false is returned, hitTestChildren() will be checked?

It's not needed for this example and I removed it.

It controls how Diagonal behaves when wrapped in a GestureDetector. When tapping the bottomLeft or topRight corner (that's not covered by one of the children) should that trigger the GestureDetector or not? Without this, it will not. Depending on the use case that's a fine choice.

It's a shame that "addWithPaintOffset()" effectively means hit test the child.

Maybe mention that this field is just here to support an assertion that checks for overflow at paint time.

It looks like more of this widget tree could be const?

Unfortunately, Container doesn't have a const constructor because some of its constructor asserts use non-const values. I could make this all const by replacing the Container widget with a SizedBox nested with a ColoredBox, but I think that would make the example just slightly more complicated as more people will be familiar with Container over those two widgets.

NICE