Not necessarily. The library evolution ABI for copyable types already abstracts away the precise set of accessors used by a property, revealing only get, and for mutable properties, yielding mutate and set. Internally, the property can change implementation from shared to computed get/set, and from only get/set to the full get/[yielding] mutate/set, without breaking ABI. If the type or property is frozen, one could still provide the yielding mutate as a backward compatibility entry point while providing a non-yielding mutate as a more efficient ABI for new code.
The story is somewhat more complicated for noncopyable types (for which borrow vs get is a fundamental semantic difference) and for nonescapable types (for which yielding vs returning affects the maximum lifetime bounds of the result), but given the fundamental interactions there, that seems unavoidable.