Such tags can have uses beyond getting fed back to the compiler. For instance, I do this at the top of my build tree:
make -k >& ,make-log
analyzelogfile ,make-log > ,build-summary
The analysis summarizes how many warnings and errors come from the compiler, how many other compiler errors were generated (collect2 phase), and how many linker errors were generated, by type of warning/error. This is tremendously helpful in quickly finding out whether the changes you just checked in made the situation better or worse.
For purposes of writing the analyzelogfile script, it helps a lot to have consistent structure/format of error and warning messages. Currently it's uglier than that, partly because there are multiple build phases involved (preprocessor, compiler, linker), each with its own ideas on how to print messages, and partly because I'm also maintaining portable code (Studio and GCC). I end up with a Perl script to do the analysis, and it can be hacked as new types of messages are discovered. It would be a lot nicer if the structure/format were well-defined in advance, and such tags were human-readable. Then the script would have an easier time finding and reporting the summarized data, by simply including such tags in the output along with a count of each type of tag that occurred.