@Nikola Nikolov -
Actually – it’s possible to stay updated with beta and nightly builds. It doesn’t come with core – instead you have to install the “WordPress Beta Tester” plugin

Yeah, I've been using Beta Tester for a long time now. :)

Beta Tester basically lets you choose between point releases and bleeding-edge nightlies. One would think that a Plugin named Beta Tester would include an option to update to release milestones such as Beta and RC.

Its functionality is essentially part of core now, with the available filters. But both core and the Beta Tester Plugin miss a key demographic: Theme and Plugin developers who need/want to start testing for compatibility at beta, and not before.

@Andrew Nacin -
I don’t think we’d need to actually introduce a new value for that. Running a development version is enough to receive auto-updates to that branch. Unfortunately, that means you automatically “skip” to the next branch (so you’d go directly from 3.7-RC2-golden to 3.8-alpha). I actually prefer that, because it means people continue to test trunk, rather than us losing our body of testers each release.

I don't mind being a core bleeding-edge tester. But I'm a small-time developer, and even I have a dozen Plugins, plus a Theme to support. I don't have time to try to monitor them throughout the development cycle. APIs change, things break, and although nightlies tend to be generally stable, they can cause a lot of unnecessary re-work for Theme/Plugin developers trying to keep their code compatible. Milestone releases - betas and release candidates - should have APIs stable enough that it makes sense for Theme/Plugin developers to make compatibility changes at that point.

It is standard practice (in any software project) for extension developers to begin compatibility testing at the beta stage. IIRC, it is even (or used to be) MO for the beta and RC release updates from make/core include a request for Plugin/Theme developers to begin testing their code against the release. It would be awesome if the core automatic update feature could account for that.

(And I would go with a filter rather than a wp-config constant.)

I do hope this decision is revisited in 3.8, because I think we're missing a slam-dunk opportunity to facilitate more Theme/Plugin developers to begin compatibility testing at release milestones, without having to stay on bleeding-edge nightlies.