For those who want to try things out: I put up a PR of the initial implementation here. It is made to be able to be standalone (i.e. you could grab the code independently and use it in a test project without needing to build all of Swift).
Im not sure active back-pressure applies here since the suspension cannot infer back to the set of objects that would change. Passively it of course uses async/await which does have a demand basis of 1 - so that passive back-pressure does exist.
Per your question w.r.t. to injection; that is well out of scope for this change and would really need something more involved than I'd like to tack on to this proposal (since it would most likely require some deep integration with the swift concurrency runtimes). However I would suggest you to take a look at design patterns using some AsyncSequence<Element, Failure> that can let you have modular backing sequences for the same properties.
This could probably be fixed by emitting a change event to the registrar inside of Observation itself when the death hits; that would go nicely with the nullable result of the closure.
Indirectly yes? I it is the first of its' kind and one could potentially build some things around Observed I would imagine.
It was a stumbling block for @Observed when that was introduced; it is still blocked on KeyPath properly supporting actor.