The one argument that I find convincing is that too many implementations
seem set to disallow generic combination, relying instead on fixed
tables of known/permissible combinations.
In that situation, a formally adopted character with the clearly stated
semantic of "is expected to actually render with ANY combining mark from
ANY script" would have an advantage. List-based implementations would
then know that this character is expected to be added to the rendering
tables for all marks of all scripts.
Until and unless that is done, it couldn't be used successfully in those
environments, but if the proposers could get buy-in from a critical mass
of vendors of such implementations, this problem could be overcome.
Without such a buy-in, by the way, I would be extremely wary of such a
proposal, because the table-based nature of these implementations would
prohibit the use of this new character in the intended way.
A./
