We're in agreement here. I was referring to same-actor (rather than inter actor) synchronous observation. i.e. observation within the same isolation context – such as a MainActor instance observing another MainActor instance.
However, for inter-actor asynchronous observation – observation of one isolation context from another – this pattern of Observation seems fraught with challenges.
For anything but the simplest use cases, due to the per property observation, and per destination observation semantics of Observation you'd end up with a bunch of granular asynchronous sequences each emitting fine-grained asynchronous state updates in their own indeterminate order – as is the nature of multiple async sequences. This would be incredibly hard to reason about, and exposing this as part of Observation may mask the difficulties involved in using them safely.
Maybe one way around this would be to manage a per-property multicast async sequence that is managed by the ObservationRegistrar and shared by each concurrent observer of that property. This forces updates through a single ordered channel, guaranteeing order and effectively controlling distribution. It still puts the onus on the programmer to ensure they use a single property to distribute their actor state though.
This is what I'm really looking forward to, though. It looks like you were really close to having a trailing edge observation working, so I'm excited to see it realised in the near future.