As the language in the article regarding re-reviews and the corresponding form wasn't 100% clear to me, but seemed to suggest that only requests regarding errors that were marked completely unjustified are processed further, I reached out to the quality team after support wasn't sure either. (I haven't sent the re-review request in question yet as I'd like to have a full grasp of the criteria first.)
Feedback was that requests regarding error severity will indeed not be processed as long as an error is an error.
While I understand that disputes regarding error severity might be difficult to settle at times, I'd like to point out that a higher error severity of a mistake can be far more damaging to the quality score of a translator than e.g. an additional low severity error, and that going by that response, there seems to be no protection for translators against a misclassified error.
Additionally, Gengo emphasizes the importance of its error type classifications (e.g. regarding re-reviews) and seems to take pride in their objective criteria, a clear documentation and a transparent process.
For example, the hurdle for classification as a critical error seems to be quite steep:
Critical: A significant error that changes the meaning of the original text and would require a retranslation to be usable by the customer. Examples include misrepresenting objective facts from the source, mistranslating vital information like a name or location, or omitting entire sections of the source text.
While the examples aren't exhaustive, I'd argue that if an error can be reasonably or even conclusively shown to not change the meaning of the original text and to not require a retranslation to be usable (as well as not matching any of the examples), it should not be marked as a critical error, and if that was done anyways, that would constitute a case which should be accepted for re-review.
So I'd like to ask Gengo to rethink its approach in that regard.
So much for the general part.
Now for my specific case, which was a compliance error. I might be in the wrong, here, as I'm obviously biased, but even if that turns out to be the case, I'd still like to uphold my request mentioned above.
If compliance errors are categorized as critical automatically, independent of their impact on the translation, I'd accept that. However, I didn't find any language regarding that in the article describing the error classifications (my apologies if I've missed anything) and I'd assume that any such omission should be interpreted in favor of the translator as the opposite wouldn't exactly be a transparent and fair process.
Even more specifically, it was a character limit that I went over. Not by much, but still. Clearly an embarrassing and completely unnecessary mistake on my part and there was also a better option available that the reviewer suggested. So I have absolutely no problem with that and have been busy kicking myself.
What I'd contest, though, is that this was a critical error.
Now I recognize that the reviewer might lack the information to assess the actual impact of such an error. There were screenshots, but I'm not sure if those are available to the reviewer, plus there is other information that I can supply that would not have been available to them readily. Seeing that limitation, an argument could be made that an error potentially being able to make a translation unusable is enough to treat it as if it actually did.
From my point of view, however, it's clear that this error had very little impact on the quality or usability of the translation. For example, as visible on the screenshots, there is no actual, critical space limitation. The limit seems to be a purely aesthetical choice, which I obviously shouldn't go against, but which wasn't impacted in a significant way, either (i.e. people would be hard pressed to even notice).
Additionally, when there was a problem with a character limit in the past, where the same customer forgot to mention a character limit in advance, they returned the collection in question for revision, which didn't happen here and would also suggest that there wasn't an actual problem. I have the collection ID at hand.