I find the naming of Path.replace quite unfortunate, coming from the os.path and basestring mindset, the expectation would be that it would change some substring by another substring in the Path instance. Instead, it _moves_ the file indicated by the Path object in the file system. Most of the methods of Path have no effect in the filesystem, and we have here one with a slightly misleading name which goes and moves your files around.

Practically the same operation is done with Path.rename, which is less surprising since it matches popular OS commands/UIs (ren, Rename).

IMHO Path.replace should not exist as is and a keyword modifier (silent?) for Path.rename toggles between the minor behavior differences of the two. 

Additionally:

Both calls lack any kind of return, which leads me to expect after a rename/replace the Path instance would be changed to the new path. This is not the case, after the call the Path instance keeps "pointing" to the previous (and quite likely now useless) path. Returning the new path would be another reasonable option. In any case, I think the documentation should mention this behavior explicitly. 

And, while we are at it, having implemented the relatively dangerous replace/rename (along with convenience shorcuts for reading, writing, opening...), why was a Path.copy not included?

Both the replace and rename functions will remain in the API, as they mirror the os module, not the os itself.  I agree that the naming is unfortunate, but it has the weight of history behind it, so we are stuck with it.  Issue 24229 rejected adding a copy method.  

Having replace and rename return a value strikes me as a good idea.  Please open a separate issue with that enhancement proposal, and nosy 'pitrou', who is the author of the pathlib module.