@Wayne-Workman (note this is not a lets beat up on Wayne thread).
While I go about this a different way, I can surely see value for this feature in a SMB or enterprise environment. If you look at it from a work flow standpoint, if I have a key associated with an image then as the workstation goes through its life cycle I can be sure that when I change the image that is deployed to the host, it will always get the proper key for activation. In addition when you look at the host record, you will see the key used to activate the host. Yes it could be done with groups but its just one more step that the Deployment Tech has to do for every system. FOG should be focused on reducing the number of steps to produce a solid image and not by adding more (case in point the persistent groups plugin (hack) )
And also consider image deployment using only iPXE and the FOS engine. Lets say you deploy an image via quick image (ok so I forgot the new name of the function). From quick/instant image you can select any image for deployment. If the key is attached to the image then the proper key will be assigned to the target computer without requiring FOG Management console access/interaction.
I can foresee a few caveats here too. If you have a host defined OEM key assigned to a host and then you assign an image to that host that contains a VLK key reference, your OEM key will be replaced with the VLK key potentially loosing your OEM key for every. But in most enterprises you don’t deploy with OEM keys anyway. But the point is you MUST be aware of this condition if you enable/deploy images that have a key association.
I surely see this as a value-add feature.