Allow Suspense Mismatch on the Client to Silently Proceed #16943
This fixes #16938 but isn't actually the semantics we want for this case.
As described in: #16938 (comment)
This would silently try to hydrate bad mismatches instead of gracefully regenerate the content on the client. Additionally, the only time the hack makes sense is if you can guarantee that nothing will possibly suspend during hydration. If it does, it opens up a whole new set of issues as the fallback would now try to hydrate.
So it's clear to me that we don't actually want this to be the semantics.
Now the debate is in whether it's ok to change this in a minor. We'd argue that it is because conditional rendering on the server is never considered a public API. E.g. if you conditionally render useLayoutEffect, Context providers or anything else, that's also not a legit usage. So technically we don't consider this a breaking change. Suspense was already erroring if used as intended - unconditionally.
However this is a technicality and it's really about what is the impact of this in practice.
…6943) * Regression test: Suspense + hydration + legacy * Allow Suspense Mismatch on the Client to Silently Proceed This fixes but isn't actually the semantics that we want this case to have.