I guess either way would function, but I think I'd rather not have that limitation. My current use case is to run my code through multiple compilers for multiple targets (a couple are GCC based, others are different). I want to merge all of those results into a single report of Compiler Warnings. As long as my number doesn't change, I'm not as worried about what the number is. However, when I'm also running my Windows target twice, once for release and once to get test coverage metrics, I can potentially get duplicate warnings if the root path is part of the check. If the warning otherwise matches (and maybe if the parser matches?, that may already be in the check), identical paths relative to the workspace root (which may not match the reported path from the compiler I suppose) should be able to be treated as one warning since in theory the same change should fix it for however many occurrences exist.
I think this is also needed in order to properly handle scans of parallel nodes. Different build nodes aren't guaranteed to have the same root folder, or if a single node is running multiple parallel blocks at once the workspace path contains @2, @3, etc... This results in the same warning getting counted either once if workspace paths match or multiple times if the workspace path does not match. We compile C++ for multiple targets in a single job, or to also run unit tests with coverage enabled, so parallel and the same compiler running on the same file is helpful and common. Storing only the relative path should mean that the same warning from different passes on the same file only gets counted once regardless of the number of times it was output.