With the ever-increasing number of available columns, courtesy of the Evaluator and the established script columns, it would be beneficial to simplify programmatic access.
How about introducing two new functions for the Evaluator and the scripting interface?
Metadata(item, column): This function returns the value of the specified column. The column can be any built-in or custom column, identified by either its name or headerkey. The item can be any file or folder.
MetadataType(column): This function returns the type of the specified column (string, date, integer, etc.), facilitating subsequent processing.
In the Evaluator, these would be standalone functions, while in the scripting interface, they could be integrated as methods within the DOpus or FSUtil object.
The Copy command e.g. would be really excited about this because it could finally match Rename's renaming features
One issue I see what that kind of API is each request would have to re-parse the file, unless there was quite complex automatic caching going on behind the scenes. E.g. If you used image width and height, they'd both need to be calculated separately. OTOH, asking for the existing image metadata object will fill everything in at once and then let you use all of those things without further calculations or re-opening the file.
But it could probably be done as part of the Item object, which could cache data for the file/folder it represents.
It'd be interesting to have something like Item.GetValue(column_keyword), unless it's just as slow or even slower than the current newer workaround.
OTH, having a new UserColumn object (maybe through DOpus.UserColumns()?) that lets you query certain columns properties, even for built-in ones (since some data changes depending on the language Opus is running in), like type, label, header, etc., would be ideal. Right now, it takes a bunch of steps to get some of that info. I'd imagine that if this were built-in, it'd be faster, even if the user had over +200 columns.