Sequence payload merges values across templates for parameters inherited from a shared base class #620

constructSelectionPath (client/src/interpreter/interpreter.ts:23) builds each selection key as `${optionPath}-${instancePath}`, where optionPath is the parameter's modelicaPath — i.e. the class where the parameter is declared. When two templates contain an instance at the same relative instancePath whose type is redeclared to different concrete classes, and the toggled parameter is declared in a common base class of those concrete classes, the optionPath (base class) and the instancePath are both identical, so the two templates produce the same key.

DownloadModal.getSequenceData() (client/src/components/modal/DownloadModal.tsx:50) then merges the per-config values under that one key into a single array, and mogrifier evaluates section toggles with any() over it — so a subsection is kept if any selected template uses the feature, and attributed to the wrong template's section in the generated document.

Root cause

The key uses the parameter's declaration site rather than a canonical Modelica path anchored at the concrete template. It should be, e.g.:

Buildings.Templates.ZoneEquipment.VAVBoxCoolingOnly.ctl.have_reqNeeCoo
Buildings.Templates.ZoneEquipment.VAVBoxReheat.ctl.have_reqNeeCoo

which are distinct and carry the template context, instead of:

Buildings.Templates.ZoneEquipment.Components.Interfaces.ControllerG36VAVBox.have_reqNeeCoo-ctl.have_reqNeeCoo

which discards it.

Impact

• mogrifier cannot resolve a toggle to the correct template's value; any() is the only thing it can do with the merged array.
• Any sequence template with per-template sections that reference an inherited parameter is affected.

Proposed fix: group by template, keep templates separate

Obsolete: see EDIT below.

EDIT on 10/8/26: change of plan ⚠️

Considering what needs to be build later, a robust hardening seems the best option, i.e., transitioning to canonical Modelica paths (actual class name-instance name).
Because

• working around the keying issue as described above forces each consumer to adopt a template scoping logic, which is both heavy and limited (e.g. how to implement a condition based on a subset of the templates);
• intuitively, canonical Modelica paths would be far more tractable to export the configured Modelica classes (as they carry both the name of the class to extend, and the class modifications to apply to it);
• if we decide to develop a Modelica record ⇄ Excel converter, we need an unambiguous address for every value. A key that only works inside a template group isn't.

Detailed specification

See https://github.com/lbl-srg/ctrl-flow-dev/blob/main/docs/selection-keys.md