I believe we have a problem that unstable features are not used by enough users to determine if they are good enough to stabilise. At the same time, I am keen not to recommend more people use Nightly Rust for obvious reasons.
I can’t think of a good solution to this dilemma. However, one bad solution might be to allow Beta users to use unstable features. I believe this is not terrible and would get us more feedback on unstable features. What do you think?
Does anyone actually use the beta? Anyways, I think the problem is that everyone wants to target stable so that people can use their libraries.
The point of beta isn’t really to actively use it, but to put it in your CI so we get early warnings if things go wrong.
I thing beta is not really used. I might be wrong though.
Why not allowing unstable features on stable rust?
The user can take a conscious decision to use an unstable feature and so, take the risk that the feature can change/disappear when a new rust version is released. I think that will make it a lot easier to test/try out unstable features.
Because stable means stable. Stability as a Deliverable | Rust Blog
You can already do exactly this: use the nightly on the day that the stable compiler is released. They'll be the same thing.
Oh, I never actually weighed in. Big 
. As @stebalien says, basically nobody uses beta: https://twitter.com/listochkin/status/674673816531021824 being the latest bit of data.
Maybe these should be provided officially? 1.5.0-stable-nightly, 1.6.0-beta-nightly, etc.
Not on the main page of course, but somewhere in official available place with the guarantee that these releases are equivalent to their stable/beta counterparts.
I would personally appreciate “special” nightly releases. I’m considering jumping on nightlies for some stuff at work to pick up catch_panic, but it feels really bad to say “download the nightly for 2015-12-05” rather than “the 1.5.0 nightly”. Betas seem like they would work for that purpose as well if feature gates were enabled for them, but it seems a bit weirder.
I think if we have a frozen version with unstable features available(beta or special nightly). It should be at least renamed to “Rust Unstable 1.x.0”
Well, “for development”. I know at least one library that was on beta for a while because of things that were not gated on nightly and beta anymore, but not in stable yet.
I assume the usage of beta will increase once people have to opt into “the next” version for a while or once version to version porting becomes more important.
I don’t think highly of allowing unstable features for beta. Beta should behave like the next stable.
I use beta because here more features (I assume), and no unstable things. If unstable code will be allowed in beta, it will just force me to switch to stable branch. I don’t use nightly because my code being deployed each day - can’t call it real production yet, but some people are working with this site and I can’t say "sorry, I need few days to remove unstable features " 
We just need to make sure that every library that works with stable rust uses the beta in their CI.
I’ve advocated for an official Unstable release before.
The lack of unstable features in anything but nightly is my biggest annoyance with Rust today. It wouldn’t be so bad if it was just waiting for features to be finished, but there’s plenty of stuff we’re never going to stabilize. This essentially means the standard library isn’t written in Rust: It’s written in unstable-rust, and mere mortal users are not allowed to compile it.
There is actually a magic flag on the compiler that lets you cheat. I’ve been meaning to write a blog post about “cracking” the DRM on the compiler to allow users to compile unstable code with a stable compiler.
Most of the time I see usage of unstable features like this, they are unnecessary. E.g., one time a library was unstable, because it opted into rustc_internal to retrieve the compiler-internal unicode tables. There's a good reason why they are unstable and forever. It's the compiler internals lib, don't touch it if you don't need to.
It is also perfectly fine that libstd is not written without feature flags: it is developed in lockstep with the compiler, as long as the external interface holds, thats all fine.
A "stable-but-with-unstable"-features can lead to de-facto standardization, which all too often is really not what you want.
This would be my preferred mechanism of using unstable. Downloading a nightly marked by an arbitrary date is fairly exhausting (imagine multirust spread across several projects with bad estimates of what date is appropriate).
Additionally, this drives the need for my participation to graduate from Rust Unstable 1.5.0 to Rust Beta 1.6.0 and Rust Stable 1.6.0 (or whatever next version removed these restrictions). Using unstable feels at the moment out-of-sync with the release train, and so I feel less incentive to test out or give feedback on impending stabilization.
cc @alexcrichton @burntsushi @aturon @Kimundi @Gankra @huon @brson (does @rust-lang/libs not work here or am I Doing It Wrong?)
Seems worth discussing at libs triage
To refocus the discussion a bit, I think this is the problem statement:
Others have pointed out other reasons for wanting a more regularly released "unstable Rust," but as far as I can see, most of them resolve to some variation of "nightly Rust is too inconvenient to use." I think that's exactly how it was intended to be. De facto stabilization is a real thing, and the more convenient we make unstable features to use, the more at risk we are for de facto stabilization. If you need to use nightly for feature X but feature X is unstable and nightly is too inconvenient, then, we should try to make feature X usable on stable (even if that means that it takes months, or perhaps in some cases, years). The inconvenience of nightly Rust has utility: it is a good forcing function to stabilize stuff that a lot of people want.
The problem stated by @nrc is directly at odds with that line of thinking though. 
I agree that it's a real problem. There are many instances where we just really need people to gain experience with a new unstable feature, e.g., the new std::panic module. If we continue to make unstable features inconvenient to use, then we aren't going to be able to collect the data we'd like, and we risk stabilizing something that has flaws that would have been uncovered with more practice.
I don't know where I land on this personally. However, I do think it's valuable to keep the key trade off in mind: risk de facto stabilization or make it harder to collect data on experience with unstable features. If we can come to a consensus on that trade off (which certainly isn't binary), then it might be easier to figure out the implementation details (like an "unstable release").
What if, for a given release, the core team can “promote” certain feature gates. This allows them to be used in beta and maybe even stable compilers. The trade-off is that all compilations using those flags print out big, scary warnings explicitly saying “this feature may or may not exist in the next release”. These gates should also be detectable via #[cfg(..)] in some fashion.
If the number of “promoted” gates is kept reasonably low, this can serve as a kind of advertisement. It’s effectively saying “hey, here are some new features we’re thinking about; please try them out, but don’t rely on them sticking around”.
If nothing else, it might be more enticing than the relative Wild West that nightly is: “here’s a big ol’ pile a stuff; some of it might get stabilised, some of it might get removed, who the hell knows, yee-haw!”
This is exactly what stabilization does for a train.
I, too, currently don’t see the point at all to Beta and I’d really like to see something like this implemented so people will have a reason to use it.
What was wrong with the old Stable - Unstable - Experimental - Deprecated system again?
Experimental could be used for most of what we consider unstable APIs today and be only accessible in the nightlies, and then APIs which are on the path to stabilization, or only have a few small hangups in their design, could be moved to Unstable and be accessible in beta.
Basically Unstable would be useful for all the currently unstable APIs which are only marked as such because they’re not battle-tested yet, but which match RFC specification and aren’t likely to change a whole lot before being stabilized. Think of a stability level that says “matches RFC specification; waiting for the dust to settle” without that needing to be added.