Currently experimental RFCs (“eRFCs”) are a second kind of RFC. That is, the “will this be implemented experimentally” bit must be set right at the outset, when the RFC is submitted. I think we should also consider adding “implement experimentally” as a 4th kind of RFC outcome (and corresponding FCP disposition), alongside the current options of accept, close, and postpone.
(As a reminder, implementing a feature experimentally (which currently applies only to eRFCs) means that a second full RFC has to go through the RFC process and be accepted before the feature can be stabilized. Incidentally, I’m not sure whether this hypothetical second RFC would be just for removing the “experimental” marker from the feature, allowing it to go through the normal stabilization process, or if it would be for the actual (immediate) stabilization-of-the-feature itself?)
When the potential benefits (and therefore importance) of an RFC is high, but there is still significant uncertainty about it, it could be an alternative to acceptance. When the cost of implementing a feature is low, it could be an alternative to postponement.
I wanted to write something more here about motivation w.r.t. how RFCs sometimes get bogged down in theoretical discussions about trying to predict their effects and that kind of thing which is really hard to know for sure without trying it, and that the current design process is “too waterfall” as someone put it, and that this could help, but I seem to be having trouble stringing coherent sentences together, so I wrote this less-coherent sentence instead.