Yes, we've given different approaches to the problem -- Mathematica gives one lots of choices!

One thing worth remembering is that Manipulate is a high level function whose purpose is to create a DynamicModule with a variety of option settings. The end result of executing a Manipulate is to create a DynamicModule expression internally (well, inside the cell it's a DynamicModuleBox...). When a Manipulate is executed with SaveDefinitions->True, the code first finds all symbols in the first argument, then it determines whether there are any preexisting definitions for those symbols. If there are any it then goes on to create a DynamicModule with those definitions within its Initialization option. When the DynamicModule is then executed, those Initializations are first executed. The result is the behavior that you notice in your simple example. At least that is roughly how it goes.

You might want to look at these if you are interested in learning more about SaveDefinitions

the-dangers-of-savedefinitions-should-this-really-happen

savedefinitions-considered-dangerous

My only experience is with using Manipulate for demos. So I was thinking in that context. When making a demo, all the code used by the notebook demo, must be included in the demo notebook, and physically be part of it. So for a demo, I do not see the point of using SaveDefinitions vs. Initialization, as one can't load external functions when the demo is deployed anyway. What I end up doing, is copy other functions I wrote from one demo to the other manually. So now I have copies of the same function in more than one demo. It is not a good way to do things, but there is no other option. It will be nice if one can load a package from a demo, and this way, one can have the same code in the package, but used by different demo notebooks.

But if you are using Initialization :> (x = 0.5)], what is point of using SaveDefinitions -> True ? Each time the Manipulate is run, x will be initialized to 0.5 before anything. I do not see the point of using SaveDefinitions and Initialization on the same symbol. Can you please explain the logic of this method?

This happens by definition. saveDefinitions means to use "saved" definitions of every symbol in Manipulate. So, when Manipulate runs, it "sees" x defined, so it uses its value. Manipulate does not know if this value came from after or before the notebook was opened, i.e. before or after current Manipulate ran. It has no time-line to know or time-stamp of each symbol.

It just sees "SaveDefinitions" there, and it also sees "x" defined, so it uses it.

I myself never use SaveDefinitions, as it causes more trouble for me than it is worth it and its semantics is fuzzy to me. I Simply use "Initialization :> (...)" in Manipulate.

Yes, it works, thank you. However I still don't understand why I need this. Isn't this something that should not happen? The variable is local, so how come it initializes with a value of another variable, especially when the initialization value is explicitly given in the code. Also, I would like to upload a demonstration to the Wolfram website, where it should be a single Manipulate. I would prefer a solution without an extra layer around it.