The principle of least astonishment suggests that a rebuild should work the same way each time; that is, it should ALWAYS start from the first stage.

We use rebuild 90% of the time, since it saves re-entering all the parameters and provides 'sensible' defaults we can just edit as needed.  (If 'Build with Parameters' used the prior run for default values, we would use that, but since it starts them all as blank, we hardly ever start pipelines that way)

We use restart from stage RARELY for intermittent deploy issues, most commonly at the later stages - for example "Prod Deploy".  However, it appears to have an undesired side-effect of altering the saved state of the pipeline so that future rebuilds will ALSO restart from stage!

This does NOT seem like a good idea.

Especially since, in practice, a long time may pass between that prior build, and a different person may be starting a new activity, so the repeat prod deployment comes as an unwelcome surprise!

Steps to reproduce:

1. With a multi-stage pipeline, build with parameters.
2. Now restart from a (later) stage - the pipeline completes.
3. (perhaps much later) Rebuild the last pipeline.

Expected result:

       The usual screen to enter parameters, with the prior job's values as defaults.

Actual result:

        The pipeline restarts from the same (later) stage as before.

In our case, this skipped the earlier build steps and prior environment deploy and test stages, and went all the way to deploy-to-prod (with the previously built and tested version) so it was basically just an unplanned re-deploy of the same code again.  Not normally harmful, but it was a factor is a series of other bad luck circumstances related to inadequate CPU capacity planning, this extra CPU load led to an unplanned prod service outage!