The implementation looks alright, but the docs need some fixes.

I am a bit unsure about this feature, but let's wait until a core dev replies to the bpo 😊

As proposed, this change need some work.

Added complexity

This change adds complexity to the already fairly complex implementation, increasing the mccabe complexity of _copytree from 18 to 20.

Generally, a mccabe complexity of > 10 is undesirable.

This suggests that the implementation is already too complex to take on additional complexity and a refactoring/redesign should be considered before bolting on more complexity.

Interacting parameters

This implementation requires the user to manage the interaction of two parameters, copy_function and copy_stat. That is, if copy_stat is used, the user is also advised to use copy_function=copyfile. It's a bad design if using one parameter implies the need to change another parameter. Instead, the caller should be able to specify each parameter independently. If there are invalid combinations of parameters, those should be explicitly disallowed. As implemented, the docs should read something like:

To disable the copying of stat for files, pass copy_function=copyfile. To disable the copying of stat for symlinks and directories, pass copy_stat=False.

It's not enough to give the user the opportunity to pass the correct arguments, it's the duty of the API designer to make it difficult if not impossible for the user to specify the wrong thing.

Passing boolean flags

I discourage the use of boolean flags to functions. Instead, it's preferable to pass the desired behavior. Similar to how copy_function allows the caller to specify the copy behavior, I'd consider if the caller could instead pass a copystat_function that defaults to copystat. Doing so would help keep _copytree more simple and would mirror the existing customization behavior.

No tests

This new behavior doesn't appear to have any tests. Covering the new behavior with tests is essential, especially the expected behavior of different combinations of interacting parameters.

I don't blame you for the approach you've taken and of course can't hold you accountable for the complexity of the current implementation. At first blush, these changes are reasonable, but they'll also introduce a lasting maintenance burden, so I'd prefer to see something of a redesign to support the necessary use-case.

I'd like to see something where copy_tree accepts a CopyHandler object, a protocol that encapsulates symlink, ignore, copy_function, ignore_dangling_symlinks, and dirs_exist_ok behaviors (and now copystat) and provides a DefaultCopyHandler that implements all of the default behaviors, but would allow a caller to readily override any of those behaviors, and most importantly would help avoid weaving the boolean values through the implementation.

If such a thing existed, the design for customizing copystat could be something like this:

class DefaultCopyHandler:
    def copy_stat(self, src, dst):
        return copystat(src, dst)

class NoStatCopyHandler(DefaultCopyHandler):
    def copy_stat(self, src, dst):
        return

copytree(..., copy_handler=NoStatCopyHandler())

I realize it's probably unfair to ask someone to take a small feature tweak and instead redesign the interface (with all of the compatibility concerns that will introduce), but I hope I've conveyed why the proposed approach is all but nonviable. If you can add tests, it's possibly acceptable, but I'd defer to the owner of shutil or another core dev to approve.