I've been thinking about the use of Observable here, and I don't think it can actually achieve what it's supposed to — it's intended for example that it could be an @State in a SwiftUI View, or that a CLI tool could iterate an async sequence of it using SE-0475. But both those use-cases require that the observer cannot miss a value from the ProgressReporter.
However, the only tool they have to observe values is withObservationTracking, which synchronously signs up to receive a notification of the next change. This is fine when mutations occur in the same isolation; you can guarantee that no mutations can occur between being notified of one mutation & signing up for the next. There's a lengthy discussion of this point in the SE-0475 review thread. However, these progress types are Sendable, and their properties may be mutated from an arbitrary isolation domain, including concurrently with the code reestablishing the withObservationTracking. I believe this guarantees that even an async sequence observing one of these types will miss progress updates. And SwiftUI is in an even worse position — it's not in any hurry to reestablish withObservationTracking for the Observable types it cares about; it "knows" everything is synchronous on the main actor. So it potentially waits nearly a whole frame (during which it will miss asynchronous updates) before reestablishing observation.
I actually think it's "unsafe" (in the sense that no observer can guarantee even eventual consistency — it's always possible that they miss the last-ever update) to have a Sendable & Observable type. But I'd like to summon @Philippe_Hausler to tell me I'm wrong...