The problem with the current system is that you get almost no testing while the flag defaults to off, and then when it defaults to on evetybody starts depending on it.

With a time-delimited system rather than a flag-delimited system, people con try things out without having to learn about flags. More importantly, they can set things up on a staging server or in a beta environment, then distribute the link to potentially non-technical stakeholders and testers without having to include detailed instructions on setting flags.

The hope is that this will lead to better feedback about medium and large scale deployment of new features, instead of only lone-web-developer feedback.

The benefit would be that - assuming the developer is well aware of this limitation - it would act as a disincentive to push code relying on the experimental feature to production.

It would however introduce a lot of hassle in testing the feature - being unable to work on a particular branch for all of every Tuesday. A better approach might be disabling it for an hour or two daily at 4am local time, or for 5 minutes per-hour, etc.

Doesn't having to ask your users to go to chrome://flags and click the "Enable" button next to some very scary looking technical text have the same effect?

I can't imagine asking users (either public or internal) to do that.

We could just ask IT to set up flags on internal applications/users if there was a business need...