The idea is not so much that you have a custom widget, but rather that you have a container view which is tightly coupled to a corresponding container widget. As you scroll, that widget requests its view to materialize (and de-materialize) views for the child widgets that become visible. It doesn't need custom widgets, the child widgets can be standard, and because it's Rust the cost of allocating and deallocating the child widgets (as opposed to recycling existing widgets as in Android RecyclerView) is modest.
(Point of clarification for those following more closely: I'm talking about views here, while the linked post is focused on widgets. The widget tree will provide a documented protocol for requesting child widgets, estimating layout sizes, syncing up scroll adjustments, and so on. This protocol will be a bit messy and complicated, because the underlying problems are hard. We'll develop it in tandem with the corresponding Xilem view, which will we hope will provide a really nice clean developer experience, especially in conjunction with an immutable list data structure which can produce sparse deltas. Then, as people want to do their own reactive layer, they can figure out how to do the plumbing from their own take on the incremental computation engine into this protocol.)
We prototyped this last year, enough to be confident in the direction, and it is absolutely a goal to wire it all up this year.