All CLA requirements met.

I think the logic should instead be: if there is one selection, delete duplicate lines like you did, but if there are multiple selections, delete duplicate selections.
IMO this handles more use cases than what you've done with multiple selections (e.g. if I select all the words I can remove duplicate words), which is equivalent to running the command on each selection separately.

Also, this would probably be closed as an "extension-candidate", which makes sense but doesn't justify having sorting commands built-in while this isn't.
Here's an extension written by someone actually in the VSCode team that does what you want -https://marketplace.visualstudio.com/items?itemName=Tyriar.sort-lines
Personally I think VSCode has no underlying logic to deciding what's built-in and what isn't, I'd vote to either having this command added or the sorting commands removed as an extension-candidate.

Btw PRs need to have an issue associated with them, I'm assuming a really old issue already exists but I couldn't find any

I think the logic should instead be: if there is one selection, delete duplicate lines like you did, but if there are multiple selections, delete duplicate selections. IMO this handles more use cases than what you've done with multiple selections (e.g. if I select all the words I can remove duplicate words), which is equivalent to running the command on each selection separately.

I based the behaviour on Sublime Text. It's also consistent with the other built-in commands, which are dealing with lines, not selections. I also think it'd just be confusing to the user if the command switched between deleting lines and deleting selections based on the amount of selections.

From personal experience, I don't recall ever needing a "delete duplicate selections" action. If there's need for it then that could just be implemented as a separate command.

Also, this would probably be closed as an "extension-candidate", which makes sense but doesn't justify having sorting commands built-in while this isn't. [...]

Yep, I agree with this, also listed this as a question above. Will leave it to project stakeholders to decide.

It's also consistent with the other built-in commands, which are dealing with lines, not selections. I also think it'd just be confusing to the user if the command switched between deleting lines and deleting selections based on the amount of selections.

Duplicate selection & Copy/Cut commands work differently based on the selection. I'd argue that a separate command is more confusing and annoying, but I guess both use cases might be useful, so idk.

Thank you!