Hi Bill,

> Is dynamic_reconfigure expected to be API stable for the C-Turtle
> release?

No, but I am aware of the growing use of dynamic_reconfigure, and am
already going to great pains not to break compatibility. Whatever
happens, there will be a very progressive transition.

> How is the startup order controlled in a launch file? As far I can tell
> the timing and order is intentionally indeterminate, so the nodes
> parameters may not be set until the node is launched. Is this correct?
> 
> <launch>
>   <node pkg="hokuyo_node" type="hokuyo_node" name="hokuyo_node"
> output="screen">
>     <param name="frame_id" value="/laser"/>
>   </node>
>   <node name="$(anon dynparam)" pkg="dynamic_reconfigure"
> type="dynparam" args="set_from_parameters hokuyo_node">
>     <param name="min_ang" type="double" value="-1.0" />
>     <param name="max_ang" type="double" value="1.0" />
>   </node>
> </launch>
> 
> Is dynamic_reconfigure seen as a replacement for the current method of
> setting parameters or should nodes support both methods for C-Turtle?

Here is what dynamic_reconfigure does:

1) At startup reads its parameters from the parameter server before
accepting any reconfigure requests.

2) Whenever there is a reconfigure request, it updates the parameter
server with the new values.

Thus, any parameters set on the node by roslaunch <param> tags will be
seen by a dynamically reconfigurable node just as it would have been by
a conventional node.

Moreover, any parameters set by dynparam will take precedence over
parameters not set by dynparam.

You probably want to write your example as:
<launch>
  <node pkg="hokuyo_node" type="hokuyo_node" name="hokuyo_node"
output="screen">
    <param name="frame_id" value="/laser"/>
    <param name="min_ang" type="double" value="-1.0" />
    <param name="max_ang" type="double" value="1.0" />
  </node>
</launch>