@frankfilipanits well yes, I am very aware of the limitations of the id = index simplification.
I agree very much with your proposed solution, which seems even more needed now that, by mean of the AudioProcessorParameter classes, the index is assigned implicitly to a parameter, based on the order of its addition to the AudioProcessor.
At least, when the getParameterXYZ(int index) methods were the only way to go, the parameter index that was being queried/referred was explicit, right there as an argument.
(somehow related to this, is this other discussion I had with jules: AudioProcessorParameter and their indices)
The only bit of your post that I don’t agree with is this:
the quick workaround @yfede suggested (a high fixed ID for bypass) won’t work because the wrappers rely on the fact that the ID is the index and vice-versa
That would be true if the parameter were to be exposed to the underlying AudioProcessor, but the VST3 bypass is not: it is entirely handled by the wrapper and that is the reason why it is given an index/id that is beyond the getNumParameters() of the AudioProcessor.
In such circumstance, that parameter is free to have an id that is different from its index, and thus my proposed workaround still seems valid to me:
set the id of the bypass to some very high, constant value, so that the indices/ids of the parameters exposed by the AudioProcessor are very far from it until the identity id==index is abandoned