Good questions. Short term, I have two issues I’d like to solve: 1) The ROS1 middleware has no security, and is therefore problematic in products. Many other issues I can address on a per-node basis, but security is reallu pervasive. 2) the ROS2 ecosystem lacks some features, particularly in libraries, that ROS1 has.
Long term, I’d like to have joint community efforts as much as possible. The bridge is problematic in this respect, mostly because of tooling. A shim for using some ROS1 libs is also problematic, but less so, IMO.
So, I would describe the goal as being able to use a ROS1-API-based node implementation in a ROS2 system as seamlessly as possible, including launching it using launch, etc.
Where to go from there, e.g. doing a full port, or keeping it like that, I can’t really say right now. I would expect that the advantages of ROS2 eventually lead to a full port. However, the shim gives users much more freedom on when to do so.
One general comment here: When discussing porting, please do not forget QA. QA for a product is quite different from what many in academia are used to. Porting a full product in one big effort is essentially a no-go, particularly, but not only, for the many applications where only a small number of units are ever sold.
Thus, a shim that starts from the existing ROS1 libs and their semantics stands a much better chance than reimplementing these APIs based on ROS2. Changing the middleware is enough of an issue as a first step. We can then gradually replace more over time, once we have a better idea of the QA issues.