> So my paint function will need to return a painted car, I will then need to sync up the state of the returned car and the car I passed in.

painted_car = car.paint()

Unless you're multithreading, there is no need to sync an object; what you get back from the call is the newest version of the object. And only crazy people want to use references with threads.

> One reason globals are bad and reference type variables are not is that a programmer can tell when a reference variable is likely going to be changed but can't for a global.

How can they tell if a referenced variable will change? Here's a method call:

foo.bar( baz )

Will baz change or not? You don't know, unless you look at bar(), and all method calls inside bar() that use baz, and all children calls in turn that use baz. I feel pretty strongly that's bad news.

By comparison, if it's a value, you know if baz will change: since you haven't used assignment here, no.

> Also, syncing state between 2 objects that initially start of as copies is, needlessly comples, error prone, and requires more memory.

The only one I agree with is the increased memory usage, and even that can be mitigated. Note that I said semantics. In a high-level language, what the machine code does underneath isn't really a concern; if the compiler can prove that no modifications will be made -- which is trivial with copy semantics -- then it'll pass a reference along. If it can't, use a copy-on-write scheme. Or just copy it.

If you really need actual references as an optimization, you can use it. I just disagree it should be the default.