I absolutely agree with the intent. Sometimes I see answers posted 1, 2, 3 years after the initial influx of answers and these late answer merely repeat what was already said. I tend to see them as attempts to farm for rep. "Surely if I add my own answer which repeats the one that has already gotten all those upvotes, I'm also going to get upvotes when people visit the question. After all, my answer is right, as evidenced by the earlier answer."
This being said...
How Much Difference is Enough?
The problem is how people will determine the "adds no more value" criterion. There are those posts that most people would immediately recognize as adding nothing. However, sometimes someone will add an answer that is basically proposing a solution that is the same as an earlier one but is explained differently. The problem is how different is different enough that the new answer is adding value?
For instance, I tend to see things more abstractedly than the average reader. If an early answers explains the solution using stack and a later answer uses graphs, but it is the same solution, it is unlikely that I will see the later answer as being different enough form the earlier one. However, I know from discussions on the Metas that some would say that there is value in explaining things differently. Some people will understand one explanation more readily than the other. I do not dispute this, but again the issue is what constitutes different enough? Because surely there are explanations that don't in fact explain things differently.
I note that the question here mentions that moderators are already handling flags to deal with such answers. However, I would suggest that users are now not actively looking for such answers to flag whereas if there is a formal flag for it, they will be actively looking for such answers to flag. So the number of flags cast if the proposal goes through should be higher than the number of flags currently cast to delete duplicate answers. However, I realize that if a new flag is introduced, it will be first handled by the community and will get to moderators only in the case where the community cannot handle it. So perhaps when everything is said and done the moderators will be burdened as much as they are now but will only handle contentious cases and this would be a net benefit. At any rate, my concern is with an outcome in which the moderators are more burdened than they are now.
Note here I'm not arguing that the mere fact that there is likely to be a substantial subjective component in the decision to flag or not is enough to make the proposal a no-go. It is merely an issue we should mitigate. The "very low quality" flag is an example of a flag that is consistently misunderstood, at least initially. People use it to flag answers that are full of typos or provide a solution without an explanation. Yes, these make the answer "very low quality" in as anybody would understand the term generally speaking but it does not qualify the answers for the "very low quality" flag.
A Departure from Other Answer Flags
The answer flags we already have typically do not require knowledge of the technologies involved. My go-to example is "Thank! Alice's answer really helped me." I don't need to know C# or SQL or any other technologies. When it comes to duplicate answers, except in the most egregious cases (e.g. cut-and-paste), I need to be able to understand the technology used. In contexts where
i++ would appear to do the same thing, there may be substantial implications that are known only to those who are working with the language. (Yes, I'm looking at you, C++.) Or an answer that looks like it is a different solution is in fact not proposing anything different. An example would be "How do I check that two jQuery objects (
$el2) that I know are collections of only one element refer to the same DOM element?" Answer 1:
$el1 === $el2
$el1.get(0) === $el2.get(0)
In my view the 2nd answer adds nothing. AFAIK, with an index of 0 and in an jQuery object that contains at least one element, the
 will return the same thing, always. Someone who does not know the technology will most likely not know this and might decide that there is in fact a difference, because, well, they look different. And in the off-chance that someone would actually argue that there is a functional difference I'm ignoring, then this person would have to know jQuery, which is precisely the point I'm making: handling such tags will often require knowing the technology used.
Again, the point here is not that this consequence kills the proposal but, you know, caveat emptor. We have to be aware of the changes this will cause. The queue these flags end up in will most likely end up being filtered by tag by those who review.