That’s a good point, but I don’t think that precludes us from adding a version to FEPs regardless. Any protocol negotiation added later can then take the version into account. I agree that the procedure you outline is not ideal, but not having versions doesn’t change it.
I mean if instead of having FEP-1a2b version 1.0.0 and FEP-1a2b version 1.1.0, we instead had FEP-1a2b and FEP-3c4d (where the latter is just an updated version of the former), you’d still need to do basically the same steps. With the versioning, you could at least use the semantic version to decide that something is still compatible, i.e. you support FEP-1a2b version 1.0.0 so therefore you should also be compatible with FEP-1a2b version 1.1.0. I think having versioning would greatly help when/if some negotiation procedure arrives some day.
Until we actually have some kind of generalized protocol negotiation, we’ll need FEPs to specify how they signal that the FEP is supported (i.e. each FEP need to specify how support is signaled to others, since there is no general mechanism to discover this). This is why I advocated for a particular addition to the type field here.
Perhaps this could be included as a reminder in the FEP template? At least until we have some kind of protocol negotiation in place. Then at least new FEPs are more likely to include some kind of explicit protocol discovery mechanism.