Modelling for change, not just for shape
Building a model that survives the revision you cannot foresee.
Modelling for change rather than just for shape means building a part with an eye toward which dimensions and features are likely to be revised later, and organising the model so that a future change can be made in one place instead of by rebuilding large sections of the history from scratch. The habit leaves no trace on the part the day it is finished, and shows itself the first time the part is asked to be different.
A toy aeroplane with a clip-on wing
A toy aeroplane built from interlocking plastic bricks, with the wing assembled as its own unit that clips onto the fuselage at a couple of fixed points, can have its entire wing redesigned (a new shape, a different span, extra detail) without touching the fuselage at all. The connection between the two halves was always narrow and deliberate, confined to those few clip points.
The same aeroplane built by gluing every brick directly onto the growing structure as it goes, with no separation between what belongs to the wing and what belongs to the fuselage, cannot have its wing redesigned without prising the whole model apart down to wherever the wing effectively started. Nothing in its construction ever drew a clean boundary between the two.
A CAD model built with deliberate sub-assemblies and clearly separated features behaves like the clip-together aeroplane under a later revision, while one built as a single, undifferentiated chain behaves like the glued one. Nobody assembling either aeroplane for the first time would notice the difference, since both produce the same finished toy, and only the person asked to change the wing afterwards discovers which one they were handed.
Two identical parts with different histories
Two models can produce an identical finished shape while being built in completely different ways underneath, and the difference appears the moment a revision is needed. A model built as one long, tightly interdependent chain of features, each referencing details of the one immediately before it, binds every later feature to the exact geometry of everything earlier in the chain. Changing an early dimension forces every later feature to recalculate against a changed foundation, and any feature that depended on a specific detail of the old geometry (an edge that has moved, a face that has shifted) can fail outright and need rebuilding by hand, sometimes several features away from the one actually edited.
A model organised around clearly separated sub-features, each referencing only what it needs instead of whatever happened to be convenient when it was created, absorbs the same change far more gracefully, because its dependencies were kept narrow and intentional. Nothing about the finished shape reveals how carefully the dependencies underneath were chosen, which is why the difference so often surfaces only once a revision is requested.
The choice can be as small as a single reference. A hole positioned from a fixed datum plane has no reason to move when an earlier feature is edited, while the same hole positioned from an edge produced by that earlier feature moves or breaks along with it. One such decision can separate a revision that takes a few minutes from one that takes an afternoon of rebuilding broken features, in two models that looked identical on the day they were finished.
Spending the care where change is likely
Anticipating which parts of a design are likely to change, such as a mounting hole's position while its surrounding bracket is still being agreed, or a wall thickness while everything else about a housing is fixed, and building those features with clean, minimal dependencies on the rest of the model, pays off well out of proportion to the modest extra planning it costs at the time. Nobody can guess every future revision correctly, and nobody needs to. What matters is noticing which dimensions carry real uncertainty during the design process and treating those with more care than a feature everyone already agrees is settled. A part still being reviewed by a customer, or still waiting on a component's final size, is exactly the kind of feature worth the attention, while a dimension nobody has questioned in months usually is not.
The same judgement works in the other direction. A simple part with no real prospect of significant revision gains little from being split into rigid sub-assemblies from the first feature, and the extra structure mostly adds overhead to building it. The discipline is worth applying in proportion to how likely real change is: heavily on a bracket still being iterated with a customer, lightly on a fastener whose shape was fixed by a published standard years before the model was drawn. Applying it uniformly everywhere spends effort on parts of a model that were never going to need it.
Learning which features will move
Judging that likelihood is itself a skill that takes practice, and a beginner usually gets it wrong in both directions before developing a reliable feel for it. Early on, the tendency is to build everything as one long chain because that is the quickest way to reach a finished shape, and the cost only appears at the first revision. After a few painful rebuilds, the tendency swings the other way, towards separating and datum-referencing every feature, including ones that will never change.
A useful middle course is to ask, for each feature as it is created, what it will need to follow if something upstream moves. If the answer is a fixed datum or a single controlling dimension, the feature is probably safe. If the answer is an edge or face created three steps earlier for some unrelated reason, the feature has picked up a dependency nobody chose, and that is the one worth fixing before the model is handed on. Enough real revisions eventually show which kinds of features in a given type of project tend to move and which stay put, and the habit settles into the right proportion.