There’s a difference between a “system” and “global”. If you’re running one robot, “system” and “global” can be relatively easily interchanged. But if you think about being able to instantiate two copies of that same robot, the robot configuration is no longer “global”. It needs to be able to be pushed down into a namespace with the robot because it may not be appropriate for both or, if there’s more, all robots to be required to have the same “awareness level” or any other system setting. Instead if you have a robot configuration management node that has these parameters each robot instance can be pointed at the appropriate configuration management node and get all this functionality with the potential additional functionality of having semantically meaningful validation and potentially application specific logic that can do things like cause one parameter change to adjust another one. This could be useful if you have a mode property that changes the validation ranges on other properties.
And if you use an introspection tool to check on robot configurations it can discover all the configuration nodes and then display what it finds for each configuration node.
One of the most valuable things about ROS APIs is that we make sure that the messages have specific semantic meaning so that they can’t be misinterpreted. As we develop the ROS 2 tools and best practices we should make sure to bring that same level of rigor to parameters too for greater reusability and correctness.