Excellent; Looking forward to seeing what you're cooking up!
The idea of explicitly storing the state of contraptions (and, more broadly, the state of applications built as decks) in widgets is an unusual feature of Decker that many beginners trip over, and I'm still trying to improve the way I explain it in the docs and tutorial materials.
I call it an "embodied data model": everything important about the state of a program in Decker has a "physical" storage location somewhere in the deck. Different widget types are designed to store different types of data: booleans in checkboxes, text in fields, etc. The ".data" attribute of fields is a sort of catchall for complex structured data, and contraptions make it possible to build custom "containers" for new kinds of data, like how all the contraptions in WigglyKit are designed to store animations. Every time Decker is finished processing an event- whether it's a change[] event triggered by a user typing in a field or a view[] event generated by Decker itself- the deck can be treated as a complete "save-state" for everything that's going on.
This model means that if you edit a script, modify the structure of a deck, or even edit a prototype definition, there's a very clear and straightforward way of understanding what information will be retained: widgets on a card retain their contents unless they're edited or removed, and the primitive widgets inside a contraption retain their "value" attributes (.value, .scroll, .row, .col, and the image on a canvas) if they've ever been modified since the contraption was created, and everything else is "inherited" from the prototype.
If there were true mutable global variables or hidden backing storage for contraption attributes, the lifespan of that information would be less clear over the course of editing, and might behave differently when loading a deck into a fresh session versus working with a deck that has been built up and edited live over the course of a session, which would be very error-prone. Everything about the design of Decker is sort of coiled around the concerns of maintaining a coherent view of the world while you build and reshape things.
Hopefully that makes some amount of sense. :)