I wonder how crates.io plays into this: i.e. should we consider also explicitly/officially encouraging people to publish things on crates.io to get experience with the API? This clearly applies to the "close the PR" option, but may also be a desirable thing to do with RFCs (and maybe even unstable APIs?) to allow interested parties to try them in their own code, and get guidance from an implementation. (And, if the RFC is eventually rejected, the functionality still exists.)
(Not everything change is going to be sane to do externally, of course, e.g. adding APIs to something complicated like HashMap may require fiddling with its internals.)
Complete brainstorming: we could have two levels of unstable, "very unstable" (A) and "normal unstable" (B), which would control how the docs are displayed (e.g. (A) might be collapsed by default, or even hidden?). Changes landing directly via PR would (usually) land as (A), and then there could be weekly/fortnightly sweeps switching (A)'s to (B) (Alternative: just have a queue that changes get added to and do rolling switches). Changes landing via RFC would land as a (A).
This has the downside of being more complicated, but has the upsides of allowing things to land more easily without losing "big picture" considerations too much, and with an easier removal path. The intention would be that users don't see much difference between the two levels of stability (other than differences in the docs).
This would benefit greatly from a nice dashboard as @alexcrichton and @aturon mention. (On that point, I'm also very keen on a dashboard even without some change like this.)
For landed APIs, I idly wonder if @nrc's work on DXR could be very useful for the unstable → stable → deprecated steps. If we (somehow) index all of crates.io, we could quickly pull up uses of the functionality in question. This will be most useful if/when crates.io encourages publishing binaries as well as libraries (e.g. when cargo install exists) to get a better cross-section of how things are used.