Please note that modules (and therefore module builds) may reference to multiple RPM builds. Also, the module name doesn't need to match any RPM name. Therefore getting package names from the module build name would not be possible anyway.
As an exapmple, see the following build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1057280Build name: "golang-ecosystem-2017.0-20180312141905.40a0ab3e"
If you open the modulemd [1] (a module definition file) linked at the bottom of the page, you'll see that this module build contains four RPM components (SRPMs):
* golang-github-russross-blackfriday
* go-srpm-macros
* golang-github-cpuguy83-go-md2man
* go-compilers
The page also says "Package Name golang-ecosystem" which links to a "golang-ecosystem" package [2] in Koji. That's weird, there is no such package named "golang-ecosystem". The page lists two module builds, not two package builds.
Another example, where a module references only one RPM package and the module name matches the package name:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1055922Build name: "nodejs-6-20180308155546.c2c572ec"
Here, the modulemd [3] lists just one RPM component (SRPM):
* nodejs
The page also says "Package Name nodejs" which again links to a "nodejs" package [4] in Koji. But this time, there *is* a "nodejs" package as well as a "nodejs" module. That page lists both!
An example of a "nodejs" package [5], build name "nodejs-9.8.0-1.module_1571+4f4bc63d" which is a good old NVR.
An example of a "nodejs" module [6], build name "nodejs-6-20180308155546.c2c572ec" whic is not an NVR, it's a NSVC (name, stream, version, context).
So after going through these two examples, I think this discussion should be more about:
1. storing two completely different IDs (NVR and NSVC) in the same data structure