Unexpected change in measure names after re-calling highcharts.getData() method with new measures in options.

Hello Flexmonster team,

My name is Yegor, and I would like to share with you a potentially incorrect library behavior that I encountered in an application that my team is working on. I'll attach an example below and also describe the steps to reproduce it that I followed myself.
Example: https://jsfiddle.net/sbnq71fx/

To begin with, an instance of the Flexmonster class was created with some set of data. Before making any changes to the example, I log all the measures that are currently available in the instance.

Then I call the highcharts.getData() method to build a highchart, and in the options I pass a new measure without a name, only with a uniqueName. When I re-log the available measures in the instance, we see that the new measure is included in the general list and has a name added that matches the uniqueName.

Then I make a repeated call to highcharts.getData(), where I pass 3 measures in the options, and the first of them matches the previously passed measure by uniqueName, but this time its name has been updated to normal text. In addition to it, 2 new measures are added with normal names different from their uniqueNames.

And if after this I again make a log of available measures in the instance, we will notice that for the first measure, which coincided with the measure from the previous call, the name was updated to the correct one, different from the uniqueName. But for some reason, the names of two new measures were rewritten, and now they began to coincide with the uniqueNames. This can also be seen on the chart itself, which was drawn as a result. New measures have appeared on it, the first one has a normal name, the other two have uniqueNames displayed as names.

If in the options for measures, instead of the “name” property, I use the “caption” property to pass the displayed name, then everything will work correctly, the log will show measures with the correct names, and they will also be correct on the chart. Therefore, I’m not entirely sure whether this is an expected behavior or a bug.