Hi… Yep, this kind of duality is normal.
The Fly.io platform uses a mixture of declarative and imperative styles, and the outcomes of operations depend on config files, sequences of procedural flyctl commands, and heuristics based on the set of Machines that you already do have deployed. There isn’t a “one stop shop” where every aspect of your app gets declared, although many people do expect it to tend more in that direction (when starting out).
In a certain sense: it seems that users who hold strong opinions about how updates and scaling should occur in detail gravitate toward designing and assembling an orchestrator of their own—via the Machines API, 
. It’s not as daunting as it looks at first!
Short of that, I personally prefer fly m clone, fly m update, fly m destroy, etc., instead of trying to nudge the quasi-declarative parts into following my specific intent.
Hope this helps a little!