It is important to compare only comparable things. When comparing two program runs you can try to compare the time that a process A.P0 spent in a function in run A to the time of another process B.P0 in run B with or without caring for the fact that B.P0 did only half of the work because run B used twice as much processes.
It is quite easy to see that depending on the domain decomposition or load balancing that is done in the application the meaningful mapping between the processes of two runs cannot be determined automatically. There might be even no such mapping: imagine comparing a run that did a domain decomposition of a cube into 8 processes 2x2x2 with a run that used a 3x3x3 decomposition.
But functions and function groups can be mapped between the runs just by their fully qualified name. This works as long as the structure of modules, namespaces and classes is not changed dramatically.
It is next to impossible to even enumerate all combinations of parameters that might have changed between two runs. To foresee all these cases in terms of automatically adapting GUI does not look promising.
Based on these considerations the mappings of processes, functions, communicators and message tags between the runs are handled differently:
Communicators are mapped by their Ids. Message tags are mapped literally by their value.
The mapping of processes and process groups is controlled by choosing the process aggregations for both files as outlined in Mapping of Processes.
The mapping between functions and function groups is handled automatically as outlined in Mapping of Functions.
See a suitable Process Group for the comparison between a 2 and a 4 processor run in the Process Aggregation dialog box: