No. You helped find a bug. Now, to make that finding useful for other people, you should report the bug. The behavior of previously supported functionality turning into a hard-to-decipher error message is a bug, and needs to be fixed by the developers of this thing.
Anecdote: I used to work on a software product that was used in large enterprises, was often mission-critical, and was distributed. Being distributed and having to be online 24x7 meant that we had to support rolling upgrades: While part of the cluster was still running software version N, another part was already running N+1. We always guaranteed that versions N and N+1 were fully compatible and interoperable. If necessary indefinitely: you could upgrade some of your nodes, and leave the rest, and that was OK. Usually version N+1 introduced new features (duh, that's most of the point of upgrades). In some cases, those features became available immediately on upgraded nodes; on other cases, new features only started working once every node in the cluster was up to version N+1. The release notes always explained that.
What did we do about older nodes? There are two schools of thought: First, if you have started upgrading any node to N+1, then all nodes with version N-1 or older are guaranteed to not work at all, they get ejected. We thought this was too harsh, since sometimes life is complicated, and our customers sometimes had to deal with "issues". So we instead did this: Only versions N and N+1 are guaranteed to interoperate, but in all cases, nodes that are at version N-1 will work as far as possible, and if they can't work, you will get clear error messages. And in our test labs, we actually ran through a full battery of tests with versions N-1, N and N+1 in a single cluster, making sure that the older version is at least well behaved, and hopefully mostly functional.
So what do you do if you want to remove a supported feature? You have to announce in the release notes for version N that this feature will be removed, not in version N+1, but at the earliest in N+2. That meant that all obsolete features had to be supported in at least two versions: the decision to drop a feature is made while N-1 is in the field in production, so the obsolescence notice can get printed in the release notes of version N, and it still has to work perfectly in N+1. With biannual releases, that means all of engineering and test has to keep working with an already obsolete feature. And starting in version N, we usually added code that said something like "If you want to use the obsolete feature, and the cluster has started the upgrade to version N+2, then give a polite error message explaining exactly why this isn't going to work any longer". All this is lots of work.
And your bug report might cause the maintainer of GMID to do exactly that work.
