I must have read your post too quickly (sorry) and with a Un*x bias I guess. What I meant is the following.

rename(2) semantics on Un*x is pretty consistent these days given by the "single Unix spec". One could argue ad infinitum if a good choice of semantics was made: rename just clobbers destination if it exists. IMHO this is a decent choice consistent with the positive bias Un*x calls have had from the start, which was permit as much as possible as fast as possible, OK when you look at the whole library construction from a legolike perspective.

I just tested rename with perl5.8.3 on HP-UX 11.0, and perl5.8.7 cygwin-1.5.24-2, and perl just follows the underlying lib. semantics as perldoc says. Sadly this means that the direct use of rename is likely to be non-portable, but is usually the case when you have a direct interface to system calls.

Un*x rename semantics is not enough in practice and usually you want something closer to the Un*x mv(1) semantics also defined by "the single unix spec". Especially mv does a copy/delete action when src and dest are on different filesystems. Giving us a portable useful interface should be the purpose of File::Copy:move and friends.

I remember some heated discussion on p5p (around 5.8.0 I guess) about having select with character semantics, and the motivation for some was essentially that windows does it. IMHO the whole thing was madness and a bad application of the "DWIM principle". I guess that perl, due to its Un*x heritage has given us incondicional access to low level libs, the "makes hard things possible" principle, but "DWIM" should apply to clean, powerful, platform-ind and useful abstractions.