I can understand the logic that we omit the arguments until we're sure we have the right design, but in my experience, a directory tree delete very often needs these arguments (specifically on_error)¹. Finding a read-only file partway through a directory deletion can cause the deletion to fail half-done, leaving the filesystem in a mess. And having to traverse the directory tree, either in advance or after the fact, to locate the offending file and fix the issue, can be extremely costly in a large directory structure.

To put this another way, the key benefit of on_error is to allow problems to be handled in context. Without that capability, I think I'd always advise using shutil.rmtree over Path.delete.

I'd rather defer making Path.delete public until we have the error handling sorted out, over releasing it in a state that makes it strictly worse than shutil.rmtree.

Thanks very much, that's most helpful. I'll close this PR for now, and open a new topic on the forum (in a few weeks time) about what to do with these arguments. I'll try to make the case that the number of practical on_error implementations is limited - in general you retry the unlink() or rmdir(), possibly after a chmod() and/or a time delay - and that there might be a more pathlib-y way to expose these options.

A tiny point, somewhat after the event. In the current shutil.rmtree the onerror callback has been deprecated in favour of a similar but different onexc. Same arguments apply as above, and I rather agree with @pfmoore ("the key benefit of on_error is to allow problems to be handled in context").