I totally understand this point of view, and I suppose it will be the point of view of the Language Workgroup.
At the same time, I pretty well know, from experience, how difficult it is to reach what you call an "ambitious" goal. Especially considering that inter-actor observation is not very different from same-actor observation, as soon as observer notifications are delayed (at the end of the suspension point, or on the next runloop cycle). Coding this right, while preserving useful characteristics, is excruciatingly difficult (not missing important "frames", synchronous start, etc, etc). It clearly belongs to the realm of the standard toolkit in my humble opinion. I'm sure no one thinks the observation tool I have described are trivially composable™. Yet I confidently assert that they address fairly common needs - surely not all needs¹, but fairly frequent ones.
SE-0395 courageously deals with the "ambitious" goal, but for SwiftUI only. This thread is intended to act as a wake-up call to the Language Workgroup and the SE-0395 author. Not only ObservationTracking.withTracking can not be used as a building block, and we actually have nothing to build upon, but the asynchronous sequences of SE-0395 fail to address the reasonable use cases that I have described in the original post above.
¹ I'm sincerely curious about arguments from KVO defenders.