I'm finally getting to this...The problem is that the version string rather than the id is stored both in the filter and in the bug. So there is no way to recover from renaming a version. Going forward we could store the id in the filter and in the bug, then if the version get's renamed everything gets the change. It seems that this may cause unwanted bug changes though...

You're right: we should be storing version IDs instead of version strings (everywhere). In MantisBT 1.2.0 we finally stopped storing categories as strings and instead started storing them properly as category IDs.

TL;DR: There's no 100% correct solution.

The problem is that you cannot store the actual ID in the filter, because you don't want the user to see multiple entries if they have more than one project that has versions with the same name. It 's not what users expect, and there are multiple edge cases involved that can result in the user getting zero results.

Because we can't store IDs, for the same reason of multiple disparate versions sharing the same name, we can't possibly expect MantisBT to be able to correctly update stored filters, especially in the case where one of the version names is updated but the other is not.

If we always updated the filter with the new version, half the users would be happy, and the other half would be upset because it's "broken", exactly the same as it happens if we never update the filter.

We could technically do some checks to see if it's the only version with that name, and update filters for that case, which would always be correct. However, then we have another problem where MantisBT is behaving differently based on circumstances that the user is not in control of. All of a sudden we have users reporting a bug that MantisBT only updates their filters sporadically, esp in cases where users don't have access to other private projects sharing version names.

Unassigned after having been assigned for a long time without progress.