Hi… Glancing at the source code, it’s heuristic and not nearly as simple as the above guess; there doesn’t appear to be any single Machine that’s getting selected for cloning, in particular.
It does seem to base the initial size primarily on a fold over the full set of existing volumes, though, and that could definitely be mentioned in the docs, 
.
This isn’t an official recommendation, of course, but, personally, I think that fly scale is more of a holdover of the old Nomad system, and people are mostly better off using fly vol create, fly m clone, and fly m destroy directly.
Those give you better predictability and more options—for example, starting the new Machine off with a fork of an existing volume.
Hope this helps a little!
Aside: The question of how declarative the Fly.io platform should be in general has long been debated in the forum. Whether things should be chiefly based on config files or chiefly influenced by the state built up through months of imperative flyctl calls in the terminal. It looks like Fly.io themselves are of two minds on this…
Users who have very strong opinions about how updating and scaling should be done in detail seem to gravitate toward writing their own orchestration, via the Machines API.