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:
instead you delete something like this:
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