> Giving it foo and returning baz and then making baz = to foo outside of the function means the function didn't accomplish what it needed.

It did. The change is available in the object being returned. There is no functional difference except that one is being explicit about change.

> Calling bar = foo(bar) isn't really all that OO.

I like purity, but I'm more interested in what works. The example above isn't OO (it's procedural), but let's run with the idea. Why do you care if it's OO or not? Think carefully about why OO exists, and we'll argue about it.

> is better than

Actually, I think both are poor pieces of code. For the first, why are you mutating an object like that inside a comparison? The same applies with foo() in the second: you're trying to do too much with one function.

Also, sane languages allow multiple return values, but if you're getting multiple return values -- which is what you're attempting with the second example -- that's a code smell.

> It encapsulates what foo is doing much better.

How? Both have exactly the same external effect: change bar and return a status about the change.

> I would say its as easy as knowing what each call accomplishes.

Well then, what does each one print? Give it a try and tell me what you'll get with value and reference semantics.