Locals.UUT customizations deleted upon install of 2014 diskset

Question

Hi,
We have customized the UUT data type used in our customized process model to include details such as Manufacturer, hardware rev etc.  We also have the process model seqeuence source controlled under a different directory than the default location.
It seems that when loading the process model after installation, teststand has taken the liberty of deleting all of these customizations, including the sub-container "config", another data type we've customized, which contains numerous properties that we change at run time to suit the current UUT under test.  I can go and manually fix this, but I've had no problems in past update disks.  IMO this should not happen, I should get a type conflict error and a prompt to resolve. 
I did get an error upon first running prompting me to open modelsupport.seq, which I did, but it did not indicate anything had changed. 
Why did this happen, and can this behavior be avoided in future diskette installs? 
I have attached images of the data type before and after.
Attachments:
UUT data type old.PNG ‏20 KB
UUT data type 2013.PNG ‏9 KB

Answer 1

Ya I understand that, data type instances can differ, and not affect the definition, which should always be the behavior. Also it seems the definition of this locals.uut type is defined in the process model itself, not a type palette  "ini" file, as you mentioned previously. However there are many instances I am using, all within the process model (pre/post uut, setup and cleanup sequences) where an instance of this type is inserted in the parameters of these process model sequences so that changes to them can be passed on within the process model.  I am also using programatic references to runstate.locals.uut.<property> speckled throughout my sequence code.  The overwriting of the type definition broke all of this. Changes to the definition in the type palette (when the process model sequences is seleced) has always changed the contents of the instances, which has been the desired behaviour in my application. 
A large reason and advantage to use a data type is the fact you can change the definition in one place, and have the instances reflect that definition everywhere it is used, so that you do not have to comb through every instance to make identical changes.  That is in fact how I was using this type. So the "unstructured" portion of this type introduced in 2013 which is "not defined by the type definition so instances can have anything under that property and it does not get modified by the type" is completely contrary to what I think a type definition is useful for, in the case anyway.  Of course no changes to any instance should ever modify the type definition, as that would be contrary to the point of having a "definition" at all.
Due to the apparent unstructured nature of this "additionalData" container, and the fact I cannot modify the Locals.UUT type and be sure it doesn't get changed and over-written by NI, I've started the work of defining a "DUT" data type and placing this in the process model locals, the contents of this type is identical to my previous modifications to Locals.UUT.  I am about half way through combing through all of my test case sequences, of which there are many, replacing references.  Not too happy about it but a learning lesson for sure.