Mostly avoided joining this conversation because it’s hard to keep up 
though I was mentioned and now that I’m trying to invite some more folks to join me in the launch improvement work, it seems worth at least chiming in a little.
I’ll just share that I discussed a lot of the context around the pain points you’re responding to with better_launch in my ROScon talk. Which has also been covered in this thread. The slides and code snippets are available at GitHub - emersonknapp/roscon2025_launch_snippets: Slides and code snippets for ROSCon 2025 presentation "Escape Velocity: Smarter, Cleaner ROS 2 Launch Patterns, a.k.a How to write good launchfiles"
It feels really unfortunate to me that the instinct is not “we can fix what we’ve got to be easier to use” - but instead “gotta toss it all out and start over”. But I don’t blame you, there’s a lot of momentum to fight against and a blank slate is a much easier starting point.
The reasoning guiding where I put my effort right now is: the community is on average going to default to the core tooling, and rather than fragmenting. I’d rather shape what we have into what we want it to look like, even if it’s kind of slow and painful. There’s a lot of good stuff and hard iterative learnings in there that never shake out in the first pass of a new tool. That isn’t to say there isn’t room for multiple tools for similar jobs - a large enough (and that’s some indicator of health) ecosystem has overlaps.
I want to emphasize that this entity doesn’t exist in the way that you imply with statements like this. You are the ROS 2 team, if you choose to be. Launch doesn’t have any particular active team except those who volunteer to improve it.
But, without a forum for those discussions to iterate more quickly, it can be hard to build context & consensus or identify the difference between hard design constraints vs achievable usability improvements. I invite you to become that team and help lead the usability discussion ROSGraph Working Group kickoff - if you feel so inclined.