I'm excited to see proposal developing! I'd like to revisit this assertion in the proposal:
In reality, having non-observed fields in a type that is observable is uncommon.
This might often be true for UI code, but from the perspective of someone working at the model and controller API level of a large-scale application, this has not been true. I'd strongly encourage you to revise this proposal to provide observability on a per-property basis, but provide a type-level convenience for marking everything observable where desired.
There are three big problems I see with the all-or-none approach:
It is valuable for a protocol to be able to declare an observability requirement on a property it introduces. We have widespread use of this with KVO (albeit not compiler-enforced) in the application I work on. If I understand correctly, this would not be possible in the current proposal unless your protocol adds a conformance requirement for full
ObservableObject. This is not an appropriate requirement for most protocols to impose.
API should be carefully designed to not expose or encourage unintended (and untested) usage patterns. It's important to provide thoughtful observability and notification patterns in your API, and to lead clients to watch for the right changes in the right way at the right time; but the current design makes that hard. Compare this to access control: Swift doesn't default a type's properties to public just because the type is public; you need to be intentional about what you expose.
Observability correctness is not free; e.g. as this proposal discusses, sometimes it requires you to add explicit transactionality in your implementation. By making all properties observable you now need to implement correctness even for those which didn't really need observability; and you may forget to do that. In contrast, having per-property observability annotations should lead you to thoughtfully validate and implement correctness for each observable property you expose.