AlternativeRequired is indeed the polyfill I mentioned. In that case I check that the custom error message string #is one of those generated by my own script, before unsetting it. This way, if other custom errors are generated, they do not conflict.
making it easier for two different scripts to run over the same form, potentially providing two types of validation on the same form element
Yes, that's exactly my issue. Different custom errors are difficult to distinguish, as they all rely upon the same feature, and they end up overriding each other (this is particularly dangerous in case the last script to fire sets the custom error message to the empty string, thus marking the element as valid while suffering from other custom errors).
In order to sustain my request I should prove that there are a lot of pages using several scripts in order to manage different custom errors. I guesse there will be at least some, as custom validation API is easy to use and, as said elsewhere, authors are meant to do it.