An "opt into unstable features" feature

The problem

We often have the need to introduce new things into Spin that we know will need time to bake before we're happy with them. However, when releasing new features, those features are effectively "insta-stable" upon their release. This means they only have the time between merge into main until the release to get testing, and this testing can only be done by users of the canary release or those who build from source.

This often leads to a few issues:

• Features sit in development a lot longer because of the relative high bar for what it means to merge something
• Features that are not quite right need to stay in their unideal state for a long time until we have a major release where we're allowed to break things (which can be years of time)
• Maintenance burden is really high on new features that need to evolve as we search for the backwards compatible way to implement improvements instead of the easier path of breaking things.

A possible solution

It would be nice if we had some mechanism for opting into "unstable" features which were allowed to break at any time.

This could be done through an --unstable-features flag which would allow using these unstable features and which would print out a warning for each feature when it is detected that the feature is being used.

This would give us the ability to more aggressively introduce features and stabilize them when we feel ready (not just when initial development is done).

Where this would help

This would help introducing lots of currently in development features:

• https://github.com/spinframework/spin/issues/3315
• https://github.com/spinframework/spin/issues/3294

Open questions

• Should we introduce such a mechanism to spin?
• Should this be an all-or-nothing flag or should we allow opting into specific features?

Start by reviewing the linked issues #3315 and #3294 alongside the proposed --unstable-features flag. Resolve whether the mechanism should be all-or-nothing or feature-specific, then define how opt-in and per-feature warnings should work. Done means the scope and behavior are agreed well enough to implement and test.