I would really like to be able to version BetaFeatures for two reasons

1. People report on the talk page something is broken. I report I have fixed it but since it hasn't been deployed people tell me I haven't fixed it. This is unnecessary noise and frustrating for me. It would be nice to say this will be fixed in version 2.

The version would show up in the list of beta features making it easy for people to understand whether something really is broken or not.

2. It would be useful (at least to me) that on a new version a new discussion page is created when the code is deployed. This helps me group problems better.

e.g.
https://www.mediawiki.org/wiki/Talk:Beta_Features/Nearby_Pages
would become
https://www.mediawiki.org/wiki/Talk:Beta_Features/Nearby_Pages/1.0 for version 1

and
https://www.mediawiki.org/wiki/Talk:Beta_Features/Nearby_Pages/1.5 for version 1.5

I would be interested if other people would also find this useful as I'm currently drowning in feedback some useful and some not.

Re: (2) - I can't have a mediawiki.org page created whenever some extension is deployed to the test wikis. We should probably be realistic and assume that these pages will exist when the feature is deployed.

As for versioning, it's possible. I'd suggest that it would be easy enough to use the version of the extension as the splitting factor, and that the feature owner should be responsible for creating new versions' feedback pages (or redirects to old pages if necessary), but I'd be willing to explore supporting this in the framework insofar as offering a "version" field and a "separateVersionLinks" switch that would pass the version into the link message (added by edsanders earlier in the year)

Re. 2 on second thoughts I can do this myself by changing the URL manually in the code itself when registering the preference and merging the change.

A version number could be as simple as a hardcoded number in the preference hook if necessary - I just want some way of allowing people to track updates who are not technical.