From the documentation of the Prototype Interface,
Modifying the attributes of a Prototype will automatically update Contraption instances in the current deck. [...]when a definition is updated, thename
,pos
,show
,locked
,animated
,font
, andscript
attributes of Contraptions will be preserved, as well thevalue
,scroll
,row
andimage
attributes of the widgets they contain (as applicable) if they have been modified from their original values in the prototype, but everything else will be regenerated from the definition. The state of contraptions is kept, and the behavior and appearance is changed.
While it is not directly stated (and perhaps bears clarifying), the same rules apply when a deck is saved and restored; the "size" and "pos" attributes of internal widgets are discarded and regenerated based on the layout defined in the Prototype. If these properties were persistent for contraption instances it would pose problems for altering the layout of the Prototype. These constraints can be a bit annoying to work around, but the design of Decker's Contraption mechanism has to square the circle between persisting essential state and inheriting changes from a Prototype.
You could solve this problem by keeping the source of truth for the dimensions of the bounding box in another hidden auxiliary widget; perhaps a field. When a contraption is resizable you also need to be rather careful about the image content of canvases, since layout could squish the canvas and crop its content smaller. For this reason, many of the contraptions in the Bazaar use rich text fields to stash one or more images persistently.