I would maybe change the title to be something like "Redesigning stage 0 during compiler bootstrapping" (i.e. give a little bit more of a hint at who will be affected, for those not familiar with what "stage 0" is)

I might rename this to sth like "Redesigning the stage 0 compiler bootstrap sequence", not sure if that makes more sense?

Btw the heading should be removed, the title attribute in the frontmatter is authoritative. Otherwise it creates this:

I might rename this to sth like "Redesigning the stage 0 compiler bootstrap sequence", not sure if that makes more sense?

I agree to find a less dense title. Another (more verbose) proposal:

Redesigning rustc initial bootstrap stage to compile the standard library

or something like that. Titles are hard 😅

Similarly, I would put a little bit of a lead up here on why this change is desired (which I think will naturally require a little bit of background to flow well).

Yeah, previously the motivation was up front, I'll need to balance it a bit.

I also think that having to clarify that stage0 is "technically not always the beta compiler" makes things a bit harder to understand 🤔 Almost every contributor is going to have stage0 being the beta compiler so even if its not necessarily true I do wonder if it would make sense to lie a bit with a footnote the first time and then just ignore it from then on:

Although maybe this actually doesn't matter too much if you have a motivation section upfront discussing mental models so that there's already a nice intuition built for "stage0 == beta mostly sort of"

I wonder if this could do with a short summary with less of the... I hesitate to say jargon, but something like:

Generally I find the current "before/after" description to be a little bit hard to parse 🤔

I'm not sure how you'd fit in but I wonder if it'd be helpful to say something like "stage0 now always refers to things from the beta toolchain (unless otherwise customized)".

"If unstable library features are being dogfooded"

dogfooding = technical lingo, which might be ok if we assume a specific target audience. Could it be reworded to be less technical?

I can use "experimenting with unstable library features", sure.

This internal blog post is targeted towards people (compiler/library contributors) who'd already be exposed to terms like "dogfooding", but "experimenting" is less opaque, so sure.

or does x check library actually build and test it?

No, that's a mistake from moving things around, good catch

What does it mean to check the precompiled library?

It's a no-op (arguably not exactly that, it's "does nothing"/"unsupported"?), I'll reword that

I think this would really benefit from some example(s). For example, what would this look like for e.g. a new trait solving feature that requires some core lang items?

(Aside, not the right place for this, but this effectively means that such features actually will need to a stage 2 compiler to be built to properly test them, right?)

Said above, a very brief summary of this could be put at the beginning.

I have an alternative description of the motivation that I think more accurately captures the effect on combined compiler/library changes. Feel free to merge and integrate or so whatever with it that you want:

The compiler and standard library are tightly coupled. Intrinsics and lang items form a broad interface between the two, and whenever it is changed, both sides need to adjust. But the standard library supports being compiled with two different compilers, the in-tree compiler and the stage0 (beta) compiler. This means that all such changes require cfg(bootstrap) to support both compilers, which results in a lot of churn of anyone wanting to improve things that touch this area.

Yeah, I think that's a way better motivation summary. I'll need to think about how to reword this section.

Also an aside and shouldn't really be discussed here, but I personally think cfg(bootstrap) in library code is likely easier to maintain and reason about than cfg(bootstrap) in compiler code.

Though, perhaps I'm wrong, in which case I think this blog post can do better at convincing me this isn't the case.

It may be easier, but it's much more common. Instances of cfg(bootstrap) should be really rare, while in the library it's incredibly common, especially for larger refactors that were simply not done previously because it's so bad