In the future we would like to use the software to address questions about building new packaging systems vs. using existing models. Allowing for temporary introduction of hypothetical plans is an important architectural feature.

On the software methodology front, I suggest these conditions are present:

a) Many interfaces where it is hard to predict numbers & types of parameters
b) cross language development
c) lots of prototyping/testing

One kind of method that helps is to have functions that take arguments that include lookup tables with hierarchies of parameters, logically equivalent to an “in” file. There may be various sources that can provide different sections & priorities for overriding other choices. So it helps to provide that facility for all of the development languages & some method for reserving the specific names of the parameters in some hierarchy of organization. In situations where some of the variables have runtime dynamics, then it may make sense to consider giving a push-pop stack structure to the individual variables in the table. The cleanest look is referencing something like =>Name (I automatically just get top of the stack). The concept is that you want to remove shifting design clutter from your interfaces, achieve modularity of concerns, & injection, without giving up the design power/freedom/information hiding of the traditional function call stack. Where & when the code level push/pop is an acceptable substitute for the built in pass by value is a judgment that may depend on language facilities. But it seems like a judgment that individuals can make within a module they are developing in mostly 1 language.