I'd agree that pulling out the numbers would make more sense longer term.
However, I think you should consider releasing PTFs for the currently supported versions of Gen (8.x) which transitions the existing installs to using the new system. With the C target, you should be able to create symbolic links of the old names to the new ones, leaving existing applications intact (they'll chase the link) and it means as they regenerate/rebuild their load modules, they'll transition to the new ones. Theoretically, by the time they jump to a newer release, the majority of their code base would already be transitioned to the new names. Of course, that also depends on other things (like Visual Studio version compatibility etc.).
Java/C# will be a problematic pain for this, I suspect - the C# DLLs don't look like they're versioned on number, but from reading the documentation, they'll be versioned on internal packages. I suspect Java is similar, though the majority of the JARs look to have version numbers in them.
Having said that, you could label it an optional PTF, with notes indicating that it'd require the regeneration/recompile of LMs going forward. That way they can either choose to opt into the pain early, with the promise of no regeneration required at the next upgrade, or opt into the pain later, when they finally do upgrade. It could help to mitigate the risk of an upgrade if they can do it in 2 phases and shake down their application before the upgrade itself.