According to the spec, a <link rel=preload blocking=render /> would block rendering until the resource is fetched.
This behavior seems a bit off, or in other words I have doubts about it.

If taken as specified, this could lead to a FOUC - as the time between the response arrives and the font is loaded / style is parsed / script is executed is not render-blocked.

It can create strange situations, e.g. with <link rel=preload render=blocking as=script /> and a corresponding <script> without a blocking keyword. Should it or should it not block? Should it block while fetching the preload but not while executing the script? If it blocks until the script is executed, what if it's not executed at all?

OTOH, when evaluating scripts/styles, their subresources (imported scripts/styles) are already implicitly render-blocking. So re-defining them as render-blocking in the preload is redundant.

I suggest that preloads should not be render-blocking at all, and instead to allow render-blocking on particular type of resources that cannot currently do that, like fonts. Maybe:

@font-face {
  font-family: "Some external font";
  blocking: render;
}

This would also make the render-blocking part of the style's content, rather than an external side-effect of one of its headers, which would require web developers to juggle between CSS authoring and backend configuration of HTTP headers.

If we want this to affect the fetch priority, it could be something like: