I am having issues with MATLAB System blocks losing their default values under certain conditions.

I am having issues with MATLAB System blocks losing their default values under certain conditions. The root issue seems to relate to the library containing the MATLAB System blocks being opened without having a path available to the System Object. I am looking for ways to more robustly maintain the default parameter values (which are variable names supplied by a high-level masked subsystem) in a MATLAB Simulink block. Details on the implemnetation and issue include:

• Using a MATLAB System block in Simulink to implement code which was initially written in a MATLAB Function block.
• The MATLAB system block is being used to protect IP by (roughly) using the same code as the MATLAB Function block and then converting the System Object to a p-file.
• The MATLAB System block includes inputs/outputs as well as parameters.
• The MATLAB System block is placed in a library (the same block is used multiple times in the model).
• The MATLAB System block is placed inside of a masked subsystem in the library. The masked subsystem allows the user to enter parameter values which vary from block to block into the subsystem mask and then pass these to the MATLAB System block as variables. These user specified parameters may be scalars, arrays, or structures.
• Part of the reason for using a masked subsystem is that it allows the user to specify parameter values in the main Simulink model and then the code can be switched between a MATLAB Function block and a MATLAB System block in the library (A MATLAB Function block is more friendly for development and debugging, as well as apparently more robust based on the issues described here).
• The issue faced is that the parameter variable names entered into the MATLAB System block mask are not robustly maintained and are deleted under certain conditions.
• The parameter values (variable name) entered into the MATLAB System block mask are permanently lost when the base Simulink model containing the linked library block is opened, and the library path has been added, but the path to the System Object file that the MATLAB System references has not been added (so Simulink tries to open the System Object but can’t locate it), and the simulation is run. Once the path to the System Object is added (for example using the ‘addpath’ function) the MATLAB System is then able to find the System Object, but the parameter values in the MATLAB System mask have now switched back to their default (empty []) values.
• If the above sequence is followed, but the library link in the main Simulink model is disabled (or broken), then the MATLAB System block recovers the parameter values in the mask (variable names) once the path to the System Object is added.
• Similarly if the Library path and the System Object path are supplied at the same time the parameter values are not lost. The root issue seems to relate to the library being opened without having a path available to the System Object.
• Creating a mask and saving default values in a .xml file doesn’t fix this issue. With this approach when a new MATLAB System block is created it will pull the default values from the .xml file. However if the values are lost in the above sequence it will not be reinitialized from the .xml file.
• The parameters are set in the System Object using the following (simplified) code:

%Public, non-tunable properties
properties (Nontunable)
    k %Gain 
end

• No default value has been added because it does not seem possible to add a variable name as a default parameter (which would be the ideal scenario). If a variable name is added as a default value it first appears to work when viewing the mask of the MATLAB System block which correctly shows the variable name and its evaluated value (which was correct during testing). However when the code is run the MATLAB System fails as it considered the default variable to be a string rather than numeric data type (setting the default data type to double with a defined length did not help)
• I have identified several work-arounds so far including disabling the block link to the library, adding a callback to add the folder containing the System Objects to the system path whenever opening the library, and keeping the System Object in the same folder as the library to minimize the chance of the library being opened without the System Object path being defined. However none of these works-arounds seem robust when delivery code to a 3rdparty (other than perhaps disabling the library links) and are ripe for potential issues.
• Possibly all the parameters could be converted into inputs and MATLAB would presumably hold onto these values better. This approach might work but is not desirable due to the large number of variables and it would be cumbersome to transition over existing MATLAB Function blocks (which are intended here to be interchangeable with MATLAB System blocks depending on the application).
• Another possible work-around would be to abandon the use of MATLAB System block/System Object and instead include the code in a m-file (converted to a p-file) which is called from within a MATLAB function block. Because the MATLAB function block is embedded within the library the variable names would presumably not be lost even if the model was run without the path to the p-file defined.
• Ideally a variable could be set as a default value, the MATLAB documentation seems to suggest that this isn’t possible but hopefully there is some workaround for implementing this is somewhat clean and robust manner