For me, and as you've pointed out, the current doc of `Path.link_to` is already wrong and misleading. Perhaps a fix of the doc should be made as a first step.

The doc uses the expression "Create a hard link pointing to a path named target." 
But comparing this to the doc of `Path.symlink_to`, which says "Make this path a symbolic link to target.", 
(and the doc of `os.link`, which says, "Create a hard link pointing to src named dst.",)
the current doc should actually be "Create a hard link at `target` pointing to this path." Sadly the argument name can't be changed here already.

And the doc of `Path.symlink_to` even have a helpful note: "Note: The order of arguments (link, target) is the reverse of os.symlink()’s." 
We could also add one for `Path.link_to`, too, like "Note: The order of arguments (link, target) is the consistent with os.link()’s.

Based on that foundation, we could finally continue to implement the correct "Path.hardlink_to". 

We can refer to how people retained `subprocess.call` while adding a newer , preferred `subprocess.run`, by noting people to prefer `Path.hardlink_to` as it's more consistent with the `pathlib` and OOP, along with telling them the obscurity of `Path.link_to` and why it's left here for backward capability.