Dennis & Kirk,
Appreciate the response and I will try out that workaround, thanks.
In regards to;
You're welcome to call it a bug, but we would see it as a matter of differences in interpreting bit values in Maker Notes (which are not publicly documented by the manufacturers).
I would disagree here and maybe you missed my mention of the fact that every other photo app I have currently installed (Aperture/Photos/Preview, Affinity Photo, Lightroom, Capture One, PhotoMill) displays the full lens information exactly the same way. PhotoMechanic is the ONLY software displaying it differently. So yes, that is a bug and it does not seem that it is a matter of interpretation, otherwise, all these various other developers would have a different "interpretation" of that data, which is not the case. Maybe the information is not where you expect it to be.
Also, if you upload a RAW file here
http://regex.info/exif.cgi (which is based on the Exiftool), you will find that exact lens string returned in the metadata. Apparently, that information is somewhere present in the file in the right format and yet another developer is able to extract it. Your devs really should investigate why they are not able to display what everyone else does.
As for the {lens} variable; again, I'm just not understanding why a focal length value would be called {lens} and not {focalLength}. To me, this is a bug as well. From a user (as well as a dev) perspective, naming needs to make sense. This applies to the majority of these variable names, btw.
Speaking of bugs and UX; there is one more, which is that the variable list is not scrollable with the arrow keys on the keyboard. There is no way to cycle through the list of variables. Each one has to be clicked on with the mouse, in order to find out what the possibly cryptic naming could stand for, i.e. {tv}.