Cool :-)
This can't happen with SE-0395, because changes are emitted at suspension points, at which time a properly-written actor has no broken invariants.
Yes, I follow. An SE-0395 observation of \.bestPlayers and an observation of \.totalPlayerCount don't carry broken invariants.
But I have great concerns for the code that composes them together in order to reconstruct a pair of values (for display on screen, for example, or some more "serious" computations). It is the composer that I don't trust at all.
The only value I trust is the (bestPlayers, totalPlayerCount) pair, built synchronously from a sound HallOfFame instance. Once I observe ONE value (which may be a tuple or a complex struct) that is guaranteed to preserve invariants, I don't need to rely on composition on multiple values in a concurrent world, a problem that is known to be super hard.
That's the reason why I foster value observations that synchronously compose values together into one final observed value. The code that composes the observed value is obviously correct, so I'm 100% sure the observer will process sound values.
It's so simple!
And that's exactly what the body property of a SwiftUI view does: it synchronously composes values together, with full reliance on invariants, in a manner that is obviously correct.
SwiftUI is not a composer of views that can only access a single property. But that's exactly what the SE-0395 sequences foster. I do not see why only SwiftUI should be granted with this essential feature: observing several values, from several observable objects, in one stroke.
By the same principle, it's not an error for
totalPlayerCountto be observed as3at one moment, then forbestPlayers.countto be10[...] at the same moment.
Some relaxed observers don't care about invariants, and for them it's OK to have more best players that the total count. But I think a Swift Observation api should aim first at demanding observers that need to rely on invariants. And for those observers, it is unacceptable to observe the values you describe.
Imagine if your SwiftUI view would render broken invariants! What a laugh! SE-0395 makes SwiftUI able to rely on invariants, and I firmly assert that the rest of us want similar guarantees.
Support for relaxed observers is still there, because a relaxed observer is just a specific case of demanding observer that focuses on partial sets of invariant-tied values, or a composition of such observers.