How can we allow users to try out 'experimental' functionality throughout Dark?

[StachuDotNet]

It's best for us to be in the habit of releasing early, but once we put functionality out there, users can end up relying on it.

This leads to some risk of either:

• us having to maintain functionality that was incomplete, but we wanted to avail
• breaking user code

How could we allow users to test experimental functionality without having to later support it or break their code?

[StachuDotNet]

What if each user could have a Canvas that is totally wiped upon a new deploy? And/or an hour after you stop editing it?

e.g. within a [user]-preview, I could access experimental stdlib fns, http handlers/middleware. etc. We make it clear to users that everything will be wiped upon the next deploy, to totally discourage relying on experimental functionality.
Ideally, there's even some stylistic difference on this canvas, to indicate "this is the canvas that will disappear!"

A tangential benefit to this approach is that it'll push us to handle #2642

[pbiggar]

I like the idea of automatically-deleted preview "things", as a useful concept for helping out with this.

That said, I think the problem of enabling experimental features for users feature shouldn't be thought of a single feature, but rather as a UX - how does the user experience this end-to-end?

[sanderjson]

What come to mind originally for me was a visual indicator. Something like a heavy dashed line around the handler Green (live), Orange (1 week deprecated warning), Red (no longer available).

These dashed lines could connect other affected handlers for 'traceability'

Furthermore when naming them I was thinking to lead with the intended name then post fix an experimental flag. So StripePackage—Experimental instead of Experimental_Stripe_Package.

Reason is I probably want to keep up to date and eventually just drop the postfix.

One great problem (User Experience) is if experimental flag is enabled then the functionality dropped completely, not improved, or transitioned. But this was the whole point, to enable faster development without worrying about managing user expectations. Using the Green, Yellow, Red theme we can ad disclaimer text in the function description.

For acceptance a pop window is enough "I acknowledge that I have enabled X experimental factors and that I should not use these features in a production environment."