This answer builds on @AlbertRetey's answer where, in the comments, you wanted some guidance as to how Wolfram creates robust controls.

Think very carefully about the division of labor between the FE and the kernel.  You've effectively embedded the entire implementation inside the FE by putting the `update` functions in `DynamicModule`s.  Generally, this is a mistake for anything you wish to be general and nontrivial.  It's better to have the implementation be in a single, versioned, interface function which exists in kernel code that can be referenced by the control.

`IntervalSlider` provides a good example.  `IntervalSlider` typesets into something which is basically a reference to the function ``NotebookTools`CustomSliderDisplay``.  This code is still going to generate its own `DynamicModule` which, in principle, could have the same sort of naming conflicts you're pointing out.  But the code has been defined now in a private context, which means all of the `DynamicModule` variable names are now in their own context, and so it would basically take user maliciousness to cause a problem.  And many things may not need to be represented at all in a `DynamicModule`.  Your specific example falls in the latter category.

So, then, your `inner` definition might look something like this:

    ClearAll[inner, outer, update];
    Remove[update]
    inner[Dynamic[x_, args___]] := 
      Interpretation[
       Dynamic[inner`innerDisplay[1, Dynamic[x, args]], TrackedSymbols :> {}], 
       inner[Dynamic[x, args]]];
    Begin["inner`Private`"];
    update[args___] := (Print@"inner"; args@1);
    inner`innerDisplay[1, Dynamic[x_, args___]] :=      
      Slider[Dynamic[x, (x = #; update[args]) &]];
    End[]

Your typeset `Dynamic` now has exactly one kernel dependency: `innerDisplay`.  As long as you make sure that this is properly loaded, which might involve setting the outermost `Dynamic` to load a package in its `Initialization`, then you're in good shape.

The first argument of `innerDisplay` is a versioning argument.  It leaves you flexibility if you want to change things in the future while supporting backward compatibility with notebooks that have older constructs in them.