I think I understand what is happening now. The second Ravel computing Growth gets it's time domain from the intersection of GrowthRate^Nom and Inflation, and the latter's time domain is controlled by the caliper on the first ravel. So when moving the caliper on the first ravel outside what the second caliper's truncated range is, the second caliper maxes out. Then after a reset, the axis range on the second Ravel is recalculated, and you can apply the first Ravel's calipers settings to the second...
OpenSUSE build of Ravel crashes
OK - two issues - the crash was caused by an exception being bubbled up past the Ravel ACPI boundary, but more importantly, the exception was being caused by the new RSVG API not being able to handle querying the default pixel size of ravel-logo.svg. Other SVGs its was fine with. So the logic of the program has to change to tell RSVG what size it should render the image to, rather than requesting its image size and scaling. This bug doesn't affect Windows builds, for the rather boring reason that...
OpenSUSE build of Ravel crashes
This was the file causing the crash
OpenSUSE build of Ravel crashes
OpenSUSE build of Ravel crashes
Caliper inconsistency