Last but not least, I tend more towards the "rmtree" method just to make it crystal clear to everyone. Maybe docs could cross-refer both methods. Tree manipulations are inherently complicated and a lot can go wrong. Symmetry is not 100% given as you might delete more than what you've created (which was a single node path).

We already have tree removal functionality that this can use internally.

I am not much concerned about the internals; shutil.rmtree should work fine here.

I am more concerned with the external interface (see also root/base/stem) and its impression on developers.

As for the name, one thing to consider is that making a recursive tree uses an argument.

And I think the argument would need to be keyword-only to avoid accidentally invoking it.

Why not adding a new method?

I am still not convinced from a safety perspective that adding a new meaning-changing argument to a removal function is such a good idea. Just consider the following example.

When deleting /my/soon/to/be/deleted/dir, you DO NOT delete a simple directory as the method name "rmdir" would suggest:

- /my/soon/to/be/deleted/dir

instead you delete something like this:

- /my/soon/to/be/deleted/dir/d1/f1
- /my/soon/to/be/deleted/dir/d1/d3/f1
- /my/soon/to/be/deleted/dir/d1/d3/f2
- /my/soon/to/be/deleted/dir/d1/d3
- /my/soon/to/be/deleted/dir/d1/f2
- /my/soon/to/be/deleted/dir/d1/f3
- /my/soon/to/be/deleted/dir/d1
- /my/soon/to/be/deleted/dir/d2/f1
- /my/soon/to/be/deleted/dir/d2/f2
- /my/soon/to/be/deleted/dir/d2
- /my/soon/to/be/deleted/dir

That is a completely different beast (a complete tree) and there is no way back once deleted.

And there are a couple of other reasons when I look as the interface of shutil.rmtree and what "recursively" really means for pathlib.