most people agree this is a DWIM violation: this is an area where Larry blew it

It may not be a DWIM for you, but it's a DWLM (do what Larry means), and that's the only meaning that matters. In fact, I don't think it would look right for it to return the changed string. I like that I can use it as:

if (s/foo/bar/) { # yes, I replaced foo with bar
 ...
}
[download]

So, it certainly DWIMs for me.

So the actual behavior does a slightly better job of DWIM in one case, and a worse job in another case... (and now that I think of it, why not return the string in list context and the count in scalar. Wouldn't that cover both bases?).

Update: actually, there's another problem I haven't thought about -- if you're doing a map{ s///; $_ } you've got the string passed through map even if there's no match. If you had s/// return the string *only* if it were changed, then you could do an if(s///) with it (usually) but you'd probably end up a sticking a $_ on the end of your map blocks anyway, just to get the string passed through in the no match condition.

s/where Larry blew it/where Larry's brilliance is more difficult to perceive/

Right, that's a point, but the way I look at it it would still work even if s/// was returning the changed string (except, of course, when the returned string was something like zero or an empty string).

Really? Then what should s/// return if *no* substitutions took place? undef? That would make

    @new_list = map {s/foo/bar/} @old_list;
[download]

fail to do the right thing most of the time as well - it would only work if the old list only contain strings that would be affected by s///. You would still need to write that as:

    @new_list = map {s/foo/bar/; $_} @old_list;
[download]

most of the time.

Right, that's a point, but the way I look at it it would still work even if s/// was returning the changed string (except, of course, when the returned string was something like zero or an empty string).

Really? Then what should s/// return if *no* substitutions took place? undef? That would make

    @new_list = map {s/foo/bar/} @old_list;
[download]

fail to do the right thing most of the time as well - it would only work if the old list only contain strings that would be affected by s///. You would still need to write that as:

    @new_list = map {s/foo/bar/; $_} @old_list;
[download]

most of the time.

Yes, you're right. That was my first thought about how it should (or "should") work, and it was clearly ill-considered. My second thought was a little better (or so I think): s/// could have been set-up to return the count of changes in scalar context, and the string itself in list context -- though that's perhaps a bit of an abuse of the idea of "list" context, because you're never going to have more than the one string returned from a s/// (unlike a m///, which can have multiple captures). Also it would create it's own "DWIM" problem in another area... for example, while this would work:

  @transformed = map {s/$old/$new/} @raw;
[download]

This would not work:

   $_ = $raw;
   $transformed = s/$old/$new/;
[download]

Anyway, the perl 6 solution to these problems is add more contexts. If I understand correctly, in logical context s/// will return whether the change happened, in numeric context you'll get the count, and in string context it'll return the matched string.

So whether or not Larry Wall would agree that he "blew it" originally, he's going to fix the problem.