Michel Hidalgo

> A standard container for composition is nothing but a well known `launch_ros.descriptions.Node`. ...and actually, this isn't entirely true. Any node could implement [the dynamic composition API](http://design.ros2.org/articles/roslaunch.html#process-with-multiple-nodes). It's a stretch,...

> Once we start delving into the concept of having a single executable which is host to multiple nodes (not using the composable interface you mentioned) I wonder how those...

> I also was thinking about changing ComposableNode from being a subclass of Node to instead being a trait, but I kind of feel like the overhead of syntax isn't...

> @hidmic I've updated the PR based on the latest feedback. I'd been holding off to see if @ivanpauno or @wjwwood had anything else to add so I didn't clutter...

> I'm thinking that the changes within `launch` are probably a little smaller, and should have appropriate backward-compatible interfaces, so maybe focus on that part first as an individual PR,...

> Maybe, we can create a "feature" branch in `launch` and `launch_ros`, and don't merge it on master until a coherent subset of things is merged. Indeed. This is probably...

As a follow-up, the design document on static name remapping will need an update as well.

It has yet to be implemented, so if anything it has to go to the Foxy board. It was brought up during our brainstorming for Foxy, but AFAIK it has...

https://github.com/ros2/ros2/issues/881 to track progress on this topic.

@azeey @sloretz @IanTheEngineer FYI