I'd like to suggest a new process for discussing and designing features and changes to MF2: document the design in a single Markdown file before implementing it in the spec.

Today, the scope and the specification of MF2 are concrete enough to be a good base against which incremental designs can be evaluated. MF2 is also complex enough to require a good deal of consideration of how a newly introduced change interacts with other parts of the standard.

In particular, I think such documents would be the right place to gather use-cases and requirements in a way that (a) allows us to evaluate alternative designs, and (b) can be looked up in the future to understand what problem we wanted to solve.

New proposals would be made in form of PRs adding a new file to the exploration directory. (The number in the file name is the PR's number, which requires a little bit of extra effort but will help with ordering and avoiding file naming conflicts.) The discussion follows in PR's review comments. When the PR is merged, it means that the proposal can be implemented in the spec. The implementation can itself result in more discussion; sometimes certain proposal will need to be reverted.

How is this different from opening new issues with a similar template to the one I propose here? There's one crucial difference: when the proposal PR is merged, the merged document represents the up-to-date consensus. With issues, the consensus is spread across multiple comments or sometimes multiple issues, making it hard to reason about some changes after time has passed.

Not all discussions nor changes need to go through this new process. I don't know exactly what criteria to use to decide whether a change needs a design proposal doc or not. Instead I suggest a heuristic: when a reviewer says that a change would benefit from a design proposal doc, it means that it needs one :)