composition LoadNode does not set parameters for nodes in other namespaces

Bug report

Required Info:

• Operating System:
  • Ubuntu 22.04
• Installation type:
  • binaries
• Version or commit hash:
  • 16.0.7-1jammy.20231205.162058
• DDS implementation:
  • CycloneDDS
• Client library (if applicable):
  • rclcpp

Steps to reproduce issue

Some projects (in this case Nav2) have nodes that create other nodes that are not necessarily in the same namespace. When these nodes are loaded via composition, parameters passed to the LoadNode service are not propagated to these "sibling" nodes. This is a change in behavior from when not using composition: if you set parameters for the process, and then create any number of nodes, they all get their parameters.

ros2 run tf2_ros static_transform_publisher --frame-id map --child-frame-id base_link

ros2 run rclcpp_components component_container

ros2 service call /ComponentManager/_container/load_node composition_interfaces/srv/LoadNode "{ package_name: "nav2_planner", plugin_name: "nav2_planner::PlannerServer", parameters: [ {name: "global_costmap.global_costmap.resolution", value: { type: 3, double_value: "1.23"}}]}"
ros2 lifecycle set /planner_server configure
ros2 lifecycle set /planner_server activate
ros2 param get /global_costmap/global_costmap resolution

Expected behavior

ros2 param get /global_costmap/global_costmap resolution outputs 1.23

Actual behavior

ros2 param get /global_costmap/global_costmap resolution outputs 0.1 (default)

Additional information

Setting parameters in the container works for this use-case. This may be a "won't fix" if this type of node creation is not desirable, and maybe could be replaced with sub nodes.
https://github.com/ros-planning/navigation2/issues/4011

Start with the composition_interfaces/srv/LoadNode service and the rclcpp component_container entry point, then reproduce the Nav2 PlannerServer case using the commands in the issue. Trace how parameters passed to LoadNode reach nodes created in other namespaces; done means the nested global_costmap node reports resolution 1.23 instead of its 0.1 default.