To circle back on the structural nature of observable types - there are definitely use cases for things to be able to be Observable and interplay with observation that are structures; however as folks have raised there are some sharp edges. Namely of which - what happens when you copy a structure that is marked with @Observable. To go into this we can set the issue about codable/equatable question aside - (which can have a solution by making ObservationRegistrar conform to those protocols in a slightly degenerate but still valid manner).
Structures housed inside reference types make sense. They have a rooted form of identity and consequently those act more like reference types. Holding just raw values is pretty strange to observe but does not pose really that much of an issue until they hit the same problem as housed structures. That issue being mutation of a copy. Specifically when fetching out a copy of the structure and then subsequently mutating it will cause a fire of the mutation detection of the observation since they would share the same registrar. There is a solution for this; copy on write. However that seems to have more exposed potentials of issues associated with it. Currently I have a draft implementation that does work, seemingly correctly, for making the registrar a copy on write type - it makes the macro emission for the mutation side of the enclosing types that are structural actually mutate the registrar and that can then enforce a uniqueness check.
Since this review has dragged on a bit I am hesitant to include the CoW form. It is something we can do later. Code and complexity wise it is something we can come back to and add later if it really poses a distinct need. Hopefully with a bit more time for doing exploration into if that is the correct move.
Interestingly this does share some alterations with the AsyncSequence accessors (being able to observe the values emitted from a specific property). So it stands to reason that could be shared in a follow-up evolution of the APIs.
The summary is that after discussion; the right move here is to restrict the application of the macro (but not the protocol or manual usages of observation) to only class types.