generally, rustc has a pretty clear stability policy. cargo does too, informally, though it's a bit more lax in some ways (specifically, things like changing the resolver are in scope)
rustup has historically not changed enough to need one
rustup has historically not changed enough to need one
Comments
("everything" isn't acceptable, full 100% stability effectively means never adding features, nothing has full 100% stability)
Sure, but you can get most of the benefits without everything. Like rust does.
Some things are documented unstable (the size of structs, ordering of fields, ...). Some minor breaking changes are allowed (adding new trait impls, ...). In practice it's "close enough"
rustup is not rustc, the answer for rustc is not going to be the answer for rustup, the rustup team has homework to do to figure it out