Also, on line 4, should KeepDuplicates="false" deduplicate A;B;B to just A;B?

If it all worked properly, this would be a nifty replacement to the RemoveDuplicates task.

@KirillOsenkov ad

Also, on line 4, should KeepDuplicates="false" deduplicate A;B;B to just A;B?

according to this, no:

If an item is generated within a target, the item element can contain the KeepDuplicates attribute.

The Item you reference is not within a target. I just got burned by this exact issue while experimenting with the flag. I'm not sure why this distinction exists however removing it could be a breaking change.
Do we want to do something about this or is this something that needs to stay please? (I'm not aware enough of the context from which this distinction appeared to make a judgement)

Already tracked under this which is a larger refactoring effort.

I've got the logging fix ready and I will be submitting a PR shortly. However that is only a half fix. (Fixing small cosmetic issue within the scope of this ticket, leaving rest unattended)

Possible follow up:

• creating a built time opt in check (to not emit additional warning and still have a better visibility) to point out that KeepDuplicates within an Item outside a target is treated as a normal metadatum and doesn't do anything about duplicates. (Too late for making it reserved keyword since that could break people due to an error/warning emission)
• going through with the unification of the behavior.
  • create a common point for remove duplicates functionality
  • retarget the inside of the target evaluation to it
  • figure out a proper place somewhere between ProjectParser.cs and Evaluator.cs. Probably around here, though it will need support in the parser as well.
• making the documentation more explicit about this behavior. Currently it is "clear" english wise, but kind of fuzzy as in "not screaming large enough about a possible caveat"