Couldn't the wrapper just warn the user if the GV version is older than the version specified in the ini file? (Or if it's missing)
It could, but that wouldn't actually solve the problem of having the "newer" version overwritten in first place. So the installation of a newly released addon that includes an "older" runtime would spoil the experience for previously installed addons that might use a "newer" runtime.
IMHO it isn't too much to ask of a user to install GV the first time he uses a SC3/GV vessel. If an addon developer includes the GV dll that overwrites a newer version (a method I personally dislike), the user gets a warning next time a newer ini file is loaded.
Sure it isn't too much to ask, the problem here is just: what version should he install, and from where? Also: what is the metric used to define "older" and "newer"? Keep in mind that people might develop the system independent from each other. There is no single place that can be considered canonical. And even if there where, what prohibits an addon-dev to say: "hey, I just want that a little bit different here, without having to rewrite all that nifty features of the system in a custom DLL just to add my little code line", and going off to recompile it, and place it into the addon distribution?
Trying to 'protect' against ignorant users is difficult. 'Protecting' against ignorant addon devs is hopeless.
You see, in this case I oppose the term "ignorant" for users or addon devs, because the license allows them to change the code and distribute the software under the terms of the GPL. Imagine the following use case:
1. An addon-dev decides that he wants to create an addon with a small little HUD display, something (for the sake of this argument) the currently "latest" version of the "official" genericvessel doesn't support.
2. He knows a bit of C++, but doesn't want to reinvent the wheel for all the other features genericvessel already offers.
3. So he sees the source code, reads the license, and understands that since it is GPL, he can modify and redistribute it accordingly.
4. Now he has a problem: where does he upload the new patch/version to? Will it be accepted there? How fast is it going to be in the new "latest" version on the central location?
5. For some reason, his patch is rejected from the "official" genericvessel project. What now? Frustrated, the addon-dev decides to distribute his addon (a cool work that certainly will have many fans) with the modified runtime.
6. In the meantime, a new "latest", "official" version comes out, many new features of it are used by the many new addons from OHM.
7. Some user has all those new addons, and also decides to install that shiny new work of our addon-dev.
8. Unfortunately, this end-user will also be frustrated, because he can't use the new addons (fully) while the addon-dev's runtime is installed. If he overwrites it again with the "latest" one, the addon-dev's work is not fully working anymore.
A solution to this is to tell the addon-dev to simply distribute his runtime as custom DLL, e.g. mygenericvessel.dll instead of genericvessel.dll. But this is just a side-by-side solution, then. Why not provide a system that supports this right from start?