Thanks for the new thread.
Yes, the plan is to depreciate R_L. In many ways, it already is since neither Tom (@automatom) nor I want to continue to maintain it. It was and continues to be a fantastic package, but the state of the art has moved forward and R_L’s age is really starting to show. Alot of things that we “could” do to improve it likely never will because Tom’s organization now uses Fuse as a replacement and I frankly have no interest in putting more time into something that there’s momentum in the community to move away from.
There’s a real question to be asked “Why Fuse?” over others, but I can answer it from my perspective:
One of the core requirements I want to see before I inject a new dependency on the ROS 2 mobile robotics community or Nav2 userbase is maturity and product-readiness. We’re only as good as our weakest link. Fuse is being used by Locus Robotics for some time now on their fleet of thousands of robots worldwide. As far as any technology can achieve the “its ready” mark, its long since passed that.
Another is that its built on a framework for expansion for new applications, which Fuse has in spades with that intention in mind. I’ll admit just the basics of Fuse I questioned for some time why not just use Ceres directly since I had some experience with it from building SLAM Toolbox. However, I’ve come more towards the useful abstractions line of thinking. Its awesome that you can set this all up in config files with no-coding (as long as you’re using standard nav_msgs/sensor_msgs/etc).
To your comment on 2D applications → I believe you’re correct. It really is right now mainly focused on 2D constraints in planar environments. But all the types that are taken in use 3D pose and orientation representations, so its not a massive effort to add that third dimension in. The fact that this is a framework that can add new constraints like this relatively easily is a big selling point to me. This is work that would likely need to be done by someone with the interests in 3D, but we’ve already started running into those folks when we’ve been talking about GPS! I can’t promise for Polymath Robotics that they’re going to implement every single 3D model you could want, but they’ll end up doing some of the basics (e.g. Pose, Orientation) which are the basis of the remaining that should be not terribly difficult.
As to whom will do that work, that’s not well defined at this moment, but there’s far more interest and value in adding the 3D constraints to Fuse than fixing half the tickets in R_L. I’m not personally committing to doing it, but it might be a result that I do it as part of the migration.
The last big thing I look for is support: does the organization that built it actually use it and plan to continue to use it long term. I can’t put words in Locus’ mouth, but it seems that’s a Yes. Tom, Stephen, and Co. are the only ones that can answer that definitely. That’s not the same thing as corporate support (e.g. you can pay CompanyA to fix a bug or help configure your system) which Locus won’t support – but hey nor will GTSAM. I also just started this thing called Open Navigation, ya hear? Maybe that’s a role we can help fill since its definitely in the ROS 2 mobile robotics orbit and won’t be the first time I’ve played with Ceres 
So, we hit all three categories in my mind satisfactorily: Maturity, Expansion, and Support.
A separate topic might be “What about the alternatives” to which my answer would be, honestly, Stephen Williams is in a much better position to be making that argument, so I’ll defer to him and the links (that I can’t find at the moment) where he explains his thinking. I know Stephen and the team at Locus well; they’re smart folks; if he chose to rebuild something from scratch instead of using software he was deeply familiar with, I think that’s illustrative in it of itself.
I’m not taking a side as much as looking to build consensus so we can all move forward together with a solution that is maintainable, mature, and sustainable. Those elements are more important to me than having the absolute bleeding edge of research – if that bleeding-edge solution means that it can’t be easily expanded upon, used by the majority of non-expert PhD-level roboticists, and is only of marginal practical additional benefit. Plus, if its integrated as the “default” for Nav2, I’ll probably have to take some minor role in it, so those attributes are pretty important from my perspective as an open-source maintainer 
Edit: This last remark aren’t accusations about GTSAM, just general points. I care about the tech as much as the next guy, but its one axis on a multi-axis analysis that we should make sure to consider.
