I think the interface we are looking for is IStatusCodeReExecuteFeature not IStatusCodePagesFeature. The latter is added all the time to the middleware, while the first one is only added by the handler when it's dealing with the re-execution code path, which I think is what we want (and is the equivalent of isErrorHandler)

This complicates the logic a bit. We need a way to avoid writing the response (so return from RenderComponentCore method before flushing) if we expect re-execution. By "expect" re-executon I mean: status code page was set, we used to have a 200 but now we have 404. At the place where we would like to detect it, IStatusCodeReExecuteFeature is unset and we have no way of preventing starting the response.

We could set IStatusCodeReExecuteFeature for in the handler subscribed to OnNotFound event: in SetNotFoundResponseAsync. This forces us to add <Reference Include="Microsoft.AspNetCore.Diagnostics" /> to Microsoft.AspNetCore.Components.Endpoints.csproj. Is this acceptable?

Otherwise, we will return too early to handle re-execution, again this condition:

Relying on IStatusCodeReExecuteFeature fails - the result is that we always flush the response and we never have a chance to re-execute.
The problem here is that we would like to detect the page that is going to re-execute, to prevent writing to its contents, not a page that already was re-executed.

In error handler we don't have such a problem (we don't have to detect to return early) because the thrown exception does it for us. We never execute any code after RenderEndpointComponent in EH case. For 404 we have to return early based on a condition.
The most reasonable is probably IStatusCodePagesFeature->set & IStatusCodeReExecuteFeature->unset & responseCode->404.

I don't fully follow, but I don't think we need to block on this

nit: I don't think this is blocking, but we shouldn't throw for this case, noop-ing is fine.