The implicit copying behavior seems to me like it's independent of the argument passing semantics.
No, the copying behavior changes semantics as the example above makes obvious.
fact that it's passed by value is an optimization allowed
No, no. The argument absolutely must be passed by value per the language semantics. Passing by reference in the above code would print the wrong value!
The OP's question is why doesn't Swift __shared have the semantics of Rust's immutable borrow. The answer is that was not designed to. Literally the only thing it does is force a +0 calling convention at the ABI level. The source of confusion is that Swift's terminology and documentation are currently misleading.
The __shared keyword does not today and cannot ever guarantee that the argument won't be copied. Nor will __shared ever be sufficient to enforce borrowed value semantics (We aren't going to break the code above in some future release).
The only way we will ever get the semantics that Max expects for copyable types is by introducing a new keyword.
I am strongly opposed to publicly documenting the __shared keyword. It will cause unending confusion with the new keyword that we introduce to actually do whatever people now think __shared does. We can call it unowned and document that it is the required convention for borrowed values, but otherwise has absolutely no semantic effect and certainly does not provide pass-by-reference semantics.