Vote++. IMHO the problem with arbitrary cost copy construction is that abstractions that are this leaky don't actually make people's lives simpler. Abstractions (like value semantics) are supposed to make the code easier to reason about. When an abstraction forces you to think hard about things as trivial as variable assignments, I think it's better to either scrap the abstraction and require all copying to be explicit, or use a less leaky abstraction like reference counting/COW.
With regard to using reference counting/COW instead of eager copying, I understand the objection that seemingly innocent actions can throw. However, I assume when this has been mentioned in the past the exception in question was out of memory. Few programs are actually designed to handle out of memory errors anyhow, except maybe in a very generic way very far up the call stack. That's why D declares out of memory to be an Error instead of an Exception. Therefore, this issue is IMHO a non-issue. To play Devil's Advocate a little, though, I do think we've substantially mitigated the bloat issue by defining default behavior for moveFront() and friends in cases where either there's no postblit or the range returns by reference. This way you only need to care about these functions if you're writing a sealed range that you plan to put structs w/ postblits in.
