The Stages approach could provide some explicit relief for implementors that wish to explore new ideas before proposing specification change.
Changes to the language are developed by way of a process which provides guidelines for evolving an addition from an idea to a fully specified feature, complete with acceptance tests and multiple implementations.
We do have some of the process described in these stages today, but I think we're missing something around gathering more user feedback, how to handle author errors, and unlock implementor experimentation.
We seem to currently have a problem of "well, implementors did this thing, and it might be against current spec but we can't change it now". This can be frustrating for all involved.
I think we end up creating more confusion for authors the more we try to auto-fix their errors; ultimately this will be worse for the users we are trying to help. Perhaps unlocking experimentation process could make this an improved working environment for everyone.
I would like to propose that we consider adopting a process similar to The TC39 Process: https://tc39.es/process-document/
The Stages approach could provide some explicit relief for implementors that wish to explore new ideas before proposing specification change.
We do have some of the process described in these stages today, but I think we're missing something around gathering more user feedback, how to handle author errors, and unlock implementor experimentation.
We seem to currently have a problem of "well, implementors did this thing, and it might be against current spec but we can't change it now". This can be frustrating for all involved.
I think we end up creating more confusion for authors the more we try to auto-fix their errors; ultimately this will be worse for the users we are trying to help. Perhaps unlocking experimentation process could make this an improved working environment for everyone.