Unmanaged, implicit observability can lead to complex systems. Making such a capability explicit will help with that issue and Apple has a management solution in SwiftUI. But really it's up to what you make of it. A lot of the issues around KVO weren't necessarily the complexity of the observations themselves but what you did with them. We've learned a lot about that as reactive systems have become more popular. Plus KVO was just so unreliable (there was no single way to make a property KVO-compliant) it was hard to build larger systems around. A system with a well structured, reliable, explicit implementation should be far easier to get under control, especially with what we know now.
As for the pitch itself, I really appreciate the structured combination of Options and separate willSet and didSet. I do think .compareEquality should be something more like .removeDuplicates, as .compareEquality gives no indication of what it actually does (does it give me an equality result?). I also think some of the APIs could be more fluent, and I dislike get as a function prefix, it's redundant. (I also saw it pop up in the runtime attributes pitch.) So I would spell the getMember API as:
public func member<Member>(
on subject: Subject,
forProperty propertyKeyPath: KeyPath<Subject, Member>,
storingAt storageKeyPath: KeyPath<Storage, Member>,
using storage: Storage
) -> Member
There are other, similar changes, I would make (like setMember) but I'll save those for another revision.
One thing I would like to see here is performance, especially runtime CPU and memory impact. If there's no implementation yet I understand that's unknown, but I'd still like to get a feel for the goals here. I would also like see a bit more discussion about observation lifetimes, as that's always been one of the biggest issues with KVO and stream observation systems.