Initialization :>{...} is convenient when there are relatively few functions to supply to Manipulate or DynamicModule. However when there there is more complex code to supply the development process becomes unwieldy. Then developing that code in the notebook elsewhere and then and using SaveDefinitions->True is a valuable approach.

Also, expanding on Nasser's comment, you can set the context properties for your notebook using the Evaluation>Notebook Default Context menu item and, for example, choose "Unique to this Notebook" or "Unique to each Cell Group" to isolate the contexts of symbols. Also, you can edit the specific Cell to set it's specific CellContext option.

Thank you both for your comments. However, both of you give different advices on how to localize the variable. But the variable is already localized by being a control variable inside Manipulate. I don't see why it needs to be localized again. SaveDefinition may save something, but it does not change the value of the outside x. I tried it. So the outside x is not the variable Manipulate works with. How come then it uses it's value? I still think this should not happen this way.

However I found a solution. Instead of giving the starting value of x in the controller definition (which as I see it should override everything, but apparently it does not), I initialize x in the initialization part of Manipulate. The following code works for me.

Manipulate[x, {x, 0, 1}, SaveDefinitions -> True,  Initialization :> (x = 0.5)]

The value of the outside x is not changed with this version of the code either.

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.

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?

Yes, I see this logic, but I still think that this is a bug in the way Manipulate is implemented. If the first argument is a Module, then the interpreter will not look for preexisting definitions for the symbols specified as local in that Module. Since the control symbols in Manipulate are also assumed to be local (at least this is my understanding), they should be treated the same way. Probably there is a good reson why they are not. Also, apparently the initial condition for the control variable is completely ignored if a value of the control symbol is found earlier. Again, probably there is a reason for this.

Since I now understand a bit better what is going on (from the users point of view), and there is an easy way around my problem, I think I will just let it go and let the developers think about the (probably good) reasons behind their approach.