Out of everything proposed so far; this seems like the nicest syntactically for all use cases. I am not opposed to this as a solution if folks feel this is a decent way to express it. It keeps the syntax still pretty tight for the common use cases and handles the more advanced use case with a more advanced syntax. Not perfect but probably as close as we can get.
I don't wanna look like we are loosing this feedback, to address some of the issues here:
Neither of those issues are going to change the design meaningfully, but the one caveat is that some of the initial behavior may be un-avoidable across concurrency domains; e.g. if you are producing at one rate and consuming on another without a shared isolation between the two. I think the second one is addressable but the first has some consequence that may be inescapable (but thankfully is limited to only particular cases).
Async/await by nature is pull. N fetches is expected given N uses. Buffering or other such mechanisms would be the performance onus of the users of Observed.
the @isolated(any) in conjunction with the closure being marked as @Sendable are doing the heavy lifting there - if the context is non-isolated then the captures MUST be Sendable by rules of concurrency. The expected behavior for making any type Sendable is to ensure that accesses to properties and such don't tear in the first place - e.g. if Person was needed to be Sendable then it would require the developer writing that (not just for Observed usage but ALL Sendable consumption) that the type does not tear across properties and those would need to be mutated in concert just like any other type.
That is pretty much a case of bad input yielding bad results. This is the case today with SwiftUI. If you don't provide a mechanism to surface the observation then it cannot just magically detect any mutation. In that case it would just return the same thing until the property is changed AND some observable thing gets triggered. In your case we could emit a diagnostic saying no observable thing was accessed in the scope of the closure.... but that is future enhancement that can be applied later (and is more generally an Observation feature not per se an Observed feature