There’s definitely space for improving the workflow of installing ROS packages from source. However one of the tenents that we’ve worked on in the design of the ROS tools is that we want to keep different aspects separated. In particular there’s a distinction between tools that install system packages, tools that interact with source checkouts, and tools that relate to the runtime. Historically that’s, rosdep, rosinstall_generator / vcs / wstool / catkin, and the runtime tools rosmsg rossrv. In ROS 2 it’s now rosdep, rosinstall_generator & colcon, and
The ros2 command aggregates many of the runtime tools into one entry point to aid discoverability and usability.
Keeping the separation is valuable because they require different levels of access and have different levels of impact. Runtime tools generally only effect the running system and leave the system reproducible if you stop everything and restart. Similarly they also don’t require write access to your installation.
Tools to install and manipulate your workspace require write access to the workspace and change content run to run. Also if you checkout code you also need to compile and manage the workspace versions and overlays.
The third layer is the system dependency management. This requires even more access(generally sudo) to do system package installations. And it has an even broader field of effect, with it changing the behavior for all users on the system.
The tools are also deployed in different manners and need to be available at different times in the development cycle. The source workspace management tools need to be available prior to having a workspace available. Whereas the runtime tools need to be available in an active installation at runtime.
So I’d encourage you to consider improvements to the source control workflows but I would at the same time suggest not trying to tie it into the runtime command line interface. There have been several iterations of workspace management tools but much of what we’ve ended up with are the smallest atomic elements of functionality that allows users and developers to put them together in the manner that best suits them following the unix model. This is how many of the new IDEs can leverage the standalone tools and libraries to support ROS workspaces. Many IDEs can also interact with source control and depending on what your use cases are that might be another area of extension that would be valuable to explore this sort of functionality.