The steps are:

1. user starts off at #/homepage/start, clicking on the Done button of the intro overlay (screenshot [1])
2. dialog closes, exposing the start module detail view (without suggested edits) (screenshot [2], first flash)
3. page reloads and at the same time navigates to #/homepage/suggested-edits
4. while the JS spins up, user sees the server-side rendered page (fragment URL gets ignored), which is like #2 but with the suggested edits related changes (one less start module sub-item etc) (screenshot [3], second flash)
5. JS overlays the suggested edits overlay, which is in the server-side rendered HTML but hidden by default (third flash)
6. suggested edits overlay loads the first task suggestion card (fourth "flash" although this one is less jarring)

Closing the gap between 1-3 would be an easy fix, just reload without closing the dialog. The one between 5-6 can be handled with T236738: Newcomer tasks: server-side rendered version of suggested edits module, or with a loading animation. I don't think 4 can be avoided in any other way than not doing a reload in the first place (T238179: Newcomer tasks: get rid of reload after suggested edits initiation). If we go that way, then the new homepage layout (including the suggested edits module) could be loaded before closing the dialog, so there are no flashes at all.

So I think the low-effort way is keeping the dialog open while the page starts reloading, and maybe have a loading animation (or T238231: Newcomer tasks: show skeleton screen while loading although not sure if that's still low-effort, it would involve moving most of the markup that's now created via OOUI components to the server side). The high-effort way is T236738: Newcomer tasks: server-side rendered version of suggested edits module + T238179: Newcomer tasks: get rid of reload after suggested edits initiation.