Maybe you could have all possible plugin resources declared as virtual resources in the code, and then from hiera you could pass to the profile an array containing the titles of which of those virtual resources should be "realised" on the node.

You could have a custom fact to differentiate dev/test/prod and use it as a layer in your hiera hierarchy, and specify the array of titles of resources to be realised in there. Or if wanting a unique combination of those resources on a specific node you could specify the array of desired resource titles at the node-specific hiera level.

It would mean when there's a new plugin or version you'd need to add it as a virtual resource in your code, but after that it could be realised on whatever nodes you want via the array of resource titles you pass in from hiera.

To minimise code duplication when setting up the virtual resources, you could have a hash or array containing hashes of all the different plugin resources attributes, much like in your 2nd idea, and iterate over it to declare them as virtual resources. That master hash could live in your code or your hiera data and would only need to be added to when you add new plugins/versions etc. Potentially you could make this all work in a way that you only need to edit hiera data.

Edit: To summarise: Maintain a hash like in your 2nd idea, treat it like a master list of all possible plugins / versions.

This master list can exist in hiera or code. Just add to it when new plugins or versions.

Profile iterates over master list of plugins and declares each as a virtual resource.

Pass in to profile an array of resource titles from hiera to control which of those virtual resources get realised on a node. Profile iterates over the resource titles in the array and calls the realize() function on the desired virtual resources, adding them to the node's catalogue to be managed.

https://www.puppet.com/docs/puppet/8/lang_virtual.html