Please also bear in mind that without an ability to pick between release versions to install, dev/beta users are unable to report which release caused an issue for them.  Giving dev/beta users the ability to choose a version will allow those users to bisect an issue to a specific release, which will empower them to provide higher quality bug reports as well.

Having the 10 most recent OS images available in a hidden menu only on beta/dev editions, and a flag to disable automated updates at boot time, would be ideal.

Or shell commands offering the same.  Or a pointer to a Wiki page explaining how to achieve those ends in developer mode.  Obviously developers have to be able to control which version they're working on, so I'm sure functionality like this already exists.

I am afraid we don't really have this exact sort of functionality for developers, today if you want to go backwards in version, you effectively have to recover the device (there is an enterprise rollback mechanism being developed, but it also has to powerwash to go back). Internal to Google the builds of Chrome OS are available to do this though, we just don't publish them publicly anywhere outside of the update service.

Fundamentally Chrome OS is not designed to allow going backwards, so the device will generally have to be wiped to go backwards in version. This is because the user state data is only guaranteed to be forward compatible, such that user state data from version N may not be recognized by N-1. 

I suspect the ability to pin your device to a particular OS version might be feasible (it might even be possible today in dev mode with some cryptic commands) as this is an existing enterprise feature, though it only works on a per milestone basis (e.g. you can pin to R66, but not 10452.74.0). 

It would also be possible to make a more formal 'stop updating this device' flag in developer mode, today I think you can do this by disabling the update_engine service every boot, but I am not sure of an easy automated way without disabling rootfs verification. I suspect we would need to restrict this to developer mode still though, it opens more persistent security risks if this could be maliciously enabled in normal mode by an exploit.

Those all make sense to some extent.

For example on the Desktop when rolling back Chrome by a major release it will often report the profile as being in read-only mode until Chrome is updated again, sync will be disabled unless creating a new profile.  Given how the profile is the user account on ChromeOS I can see how that would get in the way of normal operation.

Let's not talk about powerwashing lol... the first thing I did was upgrade the storage and something inconvenient became something monsterously inconvenient when I found that it wants to pointlessly shred the entire storage surface at every channel change.  This despite all private data being encrypted against a keyfile that can be erased, leaving all the data unrecoverable, same as powerwashing but writing 4k instead of the entire disk.