Sorry, but it's not technically possible to let you switch between v3 & v4 plugins. A plugin has a unique ID, and is only allowed to read its own data when you open a 3DM; since the plugin ID must therefore remain constant across versions, and since you can't load two plugins with the same ID, it is necessary to install only the desired version.
Sales pitch-wise... not being in sales, I guess I'd just say the main thing for v4 is indeed GPU, which may be a bigger deal for some than others. There is a GPU roadmap published
here, and a v4 features list
here. For some people, I imagine that being able to let customers download the standalone Multilight application and play with .mxi files should be a pretty attractive feature. Beyond this I'll just say that having a fairly open development model, with substantial features being added in no-charge point releases (for example, Maxwell FIRE itself was added in a point release), it can happen that you get a release with few "new" features, especially when they involve substantial work like the GPU engine. Maxwell 3 was released around 3 years ago... I suppose we could artificially pad each new release by holding features back from point releases, but I don't think that would be too cool. For me, major release numbers are just an artificial marketing concept, which unfortunately can have a real effect when it comes to sales; the reality is that you have x-number of people continually working on a piece of software, where whatever the perception of customers may be, the only real question is whether you end up with sales enough to continue. Whether people generally prefer them or not, I think subscription models reflect the actual nature of things more accurately.
Regarding the question about linked block materials, I'm sure it seems like a simple-enough thing to address from the outside, but actually, it turns out to be not so trivial. Maybe it can help to suggest imagining that, rather than add a "(2)" to each repeated material name, the plugin instead changed the name to some random value. Because when it does that, it is only because it has no way of guaranteeing that the two "Stainless steel" materials actually bear any relation to each other. This will not be the case if the two literally are the same material -- have the same internal ID -- but you will generally only encounter this case when you copy a 3DM and then insert both the original, and the copy, into a third document.
There is, however, a special case I can look into supporting, and that would be where you link to an MXM file. Because, if you link to an MXM, the path to that MXM is guaranteed to be unique, and it would be possible for the plugin, while Rhino is reading the linked documents, to replace any references to "duplicate" materials with references to whichever material already exists, and references the same MXM.
Outside that possibility, there is also the plugin's "material grouping" feature that you might use to make the existing situation more manageable. If, in the file to be linked, you select the materials, right-click, choose Set Group and enter some name, and save the document, then when you subsequently link it into another document, those materials will appear in the specified group.
Note that there is a detail here too, also pertaining to linking MXMs; the grouping feature also works with MXMs by means of a subtle hack (since the MXM format supports no such thing): the group name is appended to the material description. This means both that the group name will not survive re-reading of the MXM, if it has no group name, and that it will be born with a group name, if the MXM has one. Which means, if you use MXM linking, and if you edit your MXM file descriptions to have groups, then they'll always appear grouped when you bring them into new documents.
