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 DynamicModules. 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.

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 DynamicModules. 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, (update[args]; x = #) &]];
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.