Experimental style spec features

[xabbu42]

Motivation

We already added some new features to the style spec and there are more to come. It is the intention to keep the style spec backwards compatible. This means that we need to be very careful when adding new features to get the style spec correct from the start as it is hard to change later. This again places a big burden on implementing new features for example in #1191.

Design Alternatives

• new features are merged to main but marked as experimental without any guarantees.
• new features are developed in a branch for potentially a long time until we have enough input and experience with it.
• new features are merged to main, but then we allow for a long dev cycle to a new release to figure out the best style spec.
• live with technical debt in the style spec
• live with breaking backward compatibility when we fix the style spec

Design

As the title suggests I'm for the first option. For this we should imho have the following:

• [ ] a way to mark parts of the style spec as experimental
• [ ] a general documentation what we mean by experimental features
• [ ] the api documentation should mark experimental features with a link to the general explanation
• [ ] an option to enable experimental features which is off by default

I do thinks we could just add some documentation and then go forward with #1191 without blocking on all the above points though.

[HarelM]

I also favor the first option. I also think there's a need to define a process of making something from experimental to officially supported so that features do not remain experimental forever or for a long time. I think this is issue is a good start for this needed discussion, thanks!